Not Receiving Notifications

Finding out about an outage from a customer is the failure this product exists to prevent, so treat a missed notification as seriously as the outage itself. The first step below tells you within a minute whether this is a configuration problem or a delivery problem, and the two have nothing in common.

Symptom

An incident is visible on your dashboard, but no email, webhook, or in-app alert arrived. Or notifications arrive for some monitors and not others, or they arrive hours late.

Likely causes

Nothing was sent:

• The event rule for that monitor kind is disabled in the notification profile, or has no channel attached.
• The monitor is muted — muting is per-monitor and time-boxed, and it is easy to set from an incident card and then forget.
• The monitor is paused, so no checks ran at all.
• Quiet hours are active. In suppress mode the notification is dropped; in digest mode it is batched and arrives later.
• The event’s severity was below the minimum severity on the escalation step.
• A failure threshold has not been met yet — a rule requiring three consecutive failures stays quiet through the first two.
• The channel’s throttle cooldown swallowed a repeat of a notification you already received.

Something was sent and did not arrive:

• The email landed in spam, or your provider dropped it outright.
• The recipient address on the channel is wrong, or belongs to someone who left.
• Your webhook endpoint returned a non-2xx status, or timed out.
• The channel is disabled.

Fix steps

1. Open Notification History in the portal (/backstage/notification-history) and filter by the affected monitor. This is the whole diagnosis in one screen. Every notification is logged as sent, failed, or suppressed, and failed and suppressed entries carry the reason.

   • No entry at all → configuration. Go to step 2.
   • Suppressed → the reason names the rule that withheld it: quiet hours, a mute, or a throttle cooldown. Go to step 3.
   • Failed → delivery. Go to step 5.
   • Sent → it left DownBad. Go to step 6.

2. Configuration. Open the monitor, then the notification profile attached to it. Inside the profile, find the section for that monitor’s kind and check three things in order: the section is enabled, the event rule you expected to fire is enabled, and it has at least one channel selected. A rule with no channel is silently a no-op.

3. Check quiet hours (/backstage/quiet-hours). Confirm the current window, the mode, and which severities it covers. Quiet hours applying to critical severity in suppress mode is almost never what you want.

4. Check the monitor is neither muted nor paused. A muted monitor keeps checking and keeps opening incidents; it just does not tell you. The mute expiry is shown on the monitor.

5. Delivery failures. For email, check spam, then confirm the recipient addresses on the channel (/backstage/channels), then allowlist the sender at your mail provider. For webhooks, confirm your endpoint answers 2xx quickly — a slow endpoint fails the same way an erroring one does.

6. Sent but never seen. The message left DownBad and your provider accepted it. Check the recipient’s filters and rules, and any mailing list or shared inbox in the path. If the channel points at a shared address, confirm someone is actually reading it.

Caution

There is no test-send button. The way to prove a change works is to watch Notification History after the next real event, so make your change and then confirm it on the next incident rather than assuming.

Prevention

• Put at least two channels on anything critical — an email channel and a webhook, or an email channel and in-app. Single-channel alerting has a single point of failure and it is usually your inbox.
• Use escalation steps so an unacknowledged notification is followed by a second one, on a different channel, after a delay you choose.
• Never route critical severity into suppress quiet hours. If you want to sleep, use digest, or narrow which severities quiet hours covers.
• Review Notification History occasionally when nothing is wrong. A channel that has been quietly failing for a month looks exactly like a month with no incidents.
• Keep channel recipients on role addresses, not on one person’s inbox.