Missing alerts

You see a red bar on the chart but no message arrived. Below is the order in which you should check.

1 · Did the alarm actually fire?

Open the channel's Events tab. Two outcomes:

• Event with severity ALARM exists at the time of the red bar. The alarm fired internally. The notification path is the problem. Go to 2.
• No event for the red bar. The alarm did not fire because either (a) the channel was in grace, (b) the rule was disabled, (c) the rule is [ok_min, ok_max] and the reading was still in range — perhaps a different rule put the chart red. Read the rule. If the rule is wrong, edit it.

2 · Was the Telegram delivery rate-limited?

OpenSense rate-limits Telegram notifications per chat at 1 message per 10 s (Telegram's bot API limit is 1 / s, but we add headroom for groups). If you fired ten alarms in one minute, six landed and four are queued. The dashboard's Outbound log shows the queue.

For HACCP this happens when the fridge door is propped open and a dozen channels trip in cascade. Solution: configure a digest policy on the channel ("notify once per 30 min if state has not changed"), not per-event.

3 · Is the Telegram bot still connected?

If you ever changed the bot's API token, the existing connection is dead silently. Symptom: Outbound shows entries with HTTP 401.

Re-link the chat: in OpenSense, Account → Integrations → Telegram → Re-link. Send /start to the bot from the destination chat again.

4 · Is the email caught by spam?

The first email from a new account often lands in Gmail's Updates tab or Outlook's Other. Common signs:

• Telegram works but email does not.
• Outbound shows email entries as 200 OK (we handed off to the SMTP relay successfully), but the user did not see them.

Add alerts@opensense.murzin.digital to the contacts in the destination mailbox. Mark one of our messages as Not spam.

If the entire org's mail server rejects us (550, 553, 554), check that your IT has not blacklisted Hetzner-hosted senders. We have SPF, DKIM and DMARC set up correctly; if a downstream filter still drops us, we can route through a SendGrid trunk on request.

5 · Is the webhook hanging?

If you configured a webhook destination (POST to your incident system), check that endpoint's logs. OpenSense times out at 5 s per request. Slow webhooks pile up in the outbound queue.

We retry on 5xx with exponential backoff (5 s, 30 s, 5 min, 30 min, 1 h, 6 h), then drop. The Outbound log shows the retry history.

6 · Was the channel in silenced state?

OpenSense supports a per-channel silence window (we do not call it muting because that word reads like the alarm did not fire; here the alarm fires, it just does not notify). If a silence window covers the event, no notification is sent. The audit trail still records the alarm.

Use silence windows for known maintenance: defrost cycles, planned power-down. Avoid silence windows for "I am tired of the dishwasher alarm" — that is what the digest policy is for.

7 · Is it the rule's grace period?

A channel with a 30-minute grace period does not fire when it briefly spikes for 5 minutes. If you see red bars on the chart that are shorter than the grace period, that is by design — the chart shows the reading state, the alarm log shows the rule state, and they are not the same.