Missing notifications

Notification was not received: quick checklist

Work through this list in order before opening a support ticket.

1. Check the alert's activity. Open the alert or incident and read the Alert activity timeline. Each attempt is logged with a reason such as delivered, failed, skipped_duplicate, quiet_hours, or skipped_no_recipient, so you can see exactly why each channel did or did not fire.
2. Check channel status. Go to Integrations (channels are also listed under Settings > Notifications > Channels). Look for any channel marked as "Error" or muted.
3. 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.
4. 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.
5. Check notification preferences. Go to Settings > Notifications > Preferences. Each event type and channel-type combination can be independently enabled or disabled.
6. 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.

Email

• 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 availability and usage come from the workspace's current On-call capability. See Settings → Billing and pricing.

• Verify your phone under Settings → Notifications and confirm the number assigned to each enabled step in your personal chain.
• Use Test my on-call on the escalation policies page to test only your chain.
• Check the alert activity for an ineligible or invalid destination.

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 a page should advance to another target, check:

• The alert resolved a policy through a routing rule, monitor policy, or workspace default.
• The policy has another step after the one that already fired.
• The configured delay for that next step has elapsed and nobody acknowledged the alert.

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

• Webhooks reference
• Integrations reference
• Prober offline