Expected notification behavior
Every reason HowlOps intentionally does not send a notification, so you can tell "working as designed" from "something's broken" before opening a ticket.
Before you file a ticket: was this expected?
Most "I didn't get paged" reports turn out to be one of the cases on this page, not a bug. HowlOps has several deliberate points in the pipeline where a notification is held back on purpose. This page enumerates all of them in one place, so you can check your specific case against the list before assuming something is broken.
For a specific incident, the fastest way to check is the Delivery trace panel on that incident's detail page. It lists every delivery attempt — target, channel, outcome, and the exact reason — for that incident only. Everything below explains what those reasons mean.
Every case below is grouped by where in this pipeline the notification was held back
Before an alert even opens
These are not "skipped notifications" — no alert exists yet, so nothing was due to send.
| Setting | What it does |
|---|---|
| Confirmation threshold (default: 2 consecutive failures) | A single failed check does not open an alert. It is not lost; it just has not crossed the threshold yet. |
| Retry on fail (off by default) | When off, a transient blip does not count until the threshold is met. When on, one prober-confirmed failure is enough. |
| Region quorum (multi-region monitors, deduplicated mode) | Below your configured quorum of failing regions, the check is a partial outage and opens at warning severity instead of paging as critical. |
See Noise control, Before an alert opens for the full detection-sensitivity picture.
The alert opened, but this delivery was held back
An alert exists in the Alerts list, but a specific notification was intentionally not sent. This is the core list — check it against your Delivery trace reason.
| Reason | What happened | Where to confirm it |
|---|---|---|
| Maintenance window | The monitor was covered by an active maintenance window with alerts suppressed. Checks kept running; paging did not. | Maintenance windows |
| Dependency suppression | A monitor you configured as a primary dependency was already down, so this alert was withheld — the parent's outage already paged you. The incident still exists and is visible. | Incident detail shows "Suppressed — dependency (parent monitor name) is down" |
| Flapping | The monitor opened 5 or more alerts within a 10-minute window. Broadcast and status-page updates are held for a 30-minute cooldown and replaced with a single "flapping" notice. Escalation is not suppressed by flapping. | Noise control, Flap suppression |
| Duplicate / already open | The alert was already open for this monitor. You are notified once when it opens and once when it recovers, not on every repeated failed check. | Noise control, Deduplication and repeats |
| Quiet hours | A non-critical alert arrived during your (or the workspace) quiet window. Chat and SMS are dropped, mobile push is dropped, email is held for the daily digest. Critical alerts always page. | Noise control, Quiet hours |
| Channel or personal preferences | The channel's event filter, the workspace event matrix, or your own notification preferences excluded this event type. | Settings → Notifications → Preferences |
| Silenced | Someone silenced the alert for N minutes. Escalation and the personal chain both pause until the window ends. | Alert shows "Silenced until …" |
| Already acknowledged | Someone else acknowledged the alert before your step or channel fired, so escalation stopped advancing before it reached you. | Alert activity shows who acknowledged and when |
| Escalation step resolved to nobody | The step's target (a schedule with nobody on-call, a deleted user, an empty team) resolved to no one. HowlOps pages the workspace owner as a last-resort safety net instead of silently dropping the page — so you may see the owner notified rather than the person you expected. | Delivery trace shows the owner as the recipient for that step |
| On-call marked unavailable | The scheduled person had Available on-call turned off (Settings → Profile) or a scheduled unavailability window active. The next person in the rotation was paged instead. | Delivery trace names who was skipped and who was paged |
| SMS / voice usage limit reached | Your metered monthly SMS or voice allotment is used and overage billing is off for that channel. | Settings → Billing |
Per-channel troubleshooting
Beyond the shared reasons above, each channel has its own way of going quiet:
| Channel | Check this first |
|---|---|
| Push | The mobile app is installed, signed in, and notification permission is granted on the device. |
| Spam/junk folder, and that your mail provider isn't blocking the sending domain. | |
| SMS / Voice | Your workspace is on paid On-call (unavailable on Free On-call) and the destination number is verified. |
| Slack / Discord / Teams / Mattermost / Google Chat | The incoming webhook URL is still valid — these providers invalidate webhooks when an integration is removed or a channel is deleted. |
| Generic webhook | Your endpoint returns a 2xx status within 10 seconds; check delivery attempts in the notification log. |
For step-by-step fixes per channel (not just "is this expected"), see Troubleshooting: missing notifications.
Still not explained?
If your case genuinely does not match anything above, it is not expected behavior — work through the missing notifications troubleshooting guide, and if that does not resolve it, contact support with the incident ID and the Delivery trace panel's contents; that reason string is exactly what support needs to diagnose it further.
Related
Was this page helpful?