Missing notifications
Diagnose why alerts or notifications are not being delivered to your channels.
Notification was not received: quick checklist
Work through this list in order before opening a support ticket.
- Check the alert's activity. Open the alert or incident and read the Alert activity timeline. Each attempt is logged with a reason —
delivered,failed,skipped_duplicate,quiet_hours,skipped_no_recipient, and so on — so you can see exactly why each channel did or did not fire. - Check channel status. Go to Integrations (channels are also listed under Settings > Notifications > Channels). Look for any channel marked as "Error" or muted.
- Check routing rules. Go to Alert settings > Routing tab. Confirm the routing rule that should match the alert is enabled and has the correct filter conditions.
- Check quiet hours. Go to Settings > Notifications > Quiet hours. During an active quiet window, non-critical chat and SMS notifications are dropped and non-critical email is held for the daily digest (when the digest is enabled). Critical alerts always page, day or night.
- Check notification preferences. Go to Settings > Notifications > Preferences. Each event type and channel-type combination can be independently enabled or disabled.
- Check Spam / Junk folder (email channels only).
Specific channel issues
Slack
- Verify the webhook URL is still valid. Slack invalidates webhooks if the integration is removed or the channel is deleted. Create a new webhook and update it in HowlOps.
- If you moved the channel to a different workspace, the webhook URL changed. Update it in HowlOps.
- Check spam and junk folders.
- Add the HowlOps sending domain to your email allowlist or safe senders list.
- If using a company email filter, ask your IT admin to whitelist the sending IP range.
PagerDuty / OpsGenie
- Go to the notification log and check the error message.
- Common error:
invalid_key. The integration key has been rotated or deleted at the provider. Create a new one and update in HowlOps. - Verify the service in PagerDuty / OpsGenie is not in maintenance mode.
SMS / Voice
SMS and Voice paging are part of paid On-call (metered — see pricing for included volume and rates). They are managed by HowlOps, so no external credentials are required.
- Confirm your workspace is on paid On-call (these channels are unavailable on the Free On-call plan).
- If SMS or voice notifications never arrive, verify the channel is enabled: Settings > Notification channels > the SMS/Voice channel.
- Check the notification log for delivery errors (e.g. unverified or invalid destination number).
Generic webhook
- Confirm your endpoint responds with a 2xx status code within 10 seconds.
- Check your server logs for the delivery attempt around the time of the incident.
- HowlOps retries up to 3 times (5 s, 30 s, 5 min). All three attempts appear in the notification log.
- Test the endpoint with the Test button on the channel settings page.
Throttling and correlation
HowlOps applies per-channel deduplication and throttling (default 5 minutes per channel + event) to prevent notification storms — the same alert is not re-sent to the same channel inside that window.
Note that correlation does not reduce the number of alerts. When many monitors fail together, HowlOps groups their alerts into a single correlated view and shows a "N monitors affected" banner, but each individual alert still fires and pages on its own. If you want a shared-cause outage to suppress child pages, set up monitor dependencies so dependent monitors are held while their parent is down (see Monitors).
Escalation policy not triggering
If the primary on-call person does not respond, escalation requires:
- An escalation policy assigned to the monitor's routing rule.
- The escalation policy has at least two levels.
- The first-level timeout has elapsed (check the policy configuration for the timeout value).
Check the incident timeline in the incident detail view, where escalation events are logged.
Monitor recovered but no recovery notification
Recovery notifications are sent automatically when an open alert resolves, and they travel the same path the alert took (the same channels or on-call people). They are opt-out per channel, not off by default. If a monitor recovered but you did not receive a recovery alert:
- Confirm an alert was actually open for that monitor. Recovery notifications only fire to close out an open alert; a transient blip that never opened one produces no recovery alert.
- Check whether recovery was intentionally silenced. The recovery (up) event can be turned off per channel in Settings > Notifications > Preferences, and the "Incidents only, no recovery noise" preset does exactly that. The alert still disappears from your open list even when the all-clear is silenced.
- Otherwise work through the quick checklist above (channel status, preferences, quiet hours); recovery uses the same channels and preferences as the original alert.
See also
Was this page helpful?