Noise control

Why this page exists

A good on-call tool is judged as much by the pages it doesn't send as the ones it does. HowlOps has several independent mechanisms that reduce noise, and they act at different stages of the pipeline. This page collects all of them so you can see what is dampening (or could dampen) an alert. For the end-to-end flow, see Alert & incident flow.

Before an alert opens: detection sensitivity

These decide whether a failing check becomes an alert at all.

Control	What it does	Where
Confirmation threshold	Requires N consecutive failed checks before an alert opens (default 2).	Per monitor
Retry on fail	The prober immediately re-checks, so one confirmed failure suffices.	Per monitor
Region quorum	Only open an alert when at least X% of regions are down. Below that, it's a partial outage and stays quiet.	Per monitor (multi-region)

Partial outages are downgraded, not silenced

When a monitor runs from several regions in the default (deduplicated) mode and only some regions fail, HowlOps treats it as a partial outage: the alert opens at warning severity instead of critical, so it flows through your normal channels as a lower-priority signal rather than a full page. If a partial outage should page like a full outage for a given monitor, turn on Treat partial outages as critical (partial_outage_critical) on that monitor. See Monitors → Degraded state.

After an alert opens: deduplication and repeats

Control	What it does	Default
Alert deduplication	While an alert is open, further failed checks for the same monitor do not open new alerts. You get one page for the outage and one for recovery.	Always on
Per-channel throttle	The same alert is not re-sent to the same channel within a window.	5 minutes per channel + event
Renotify interval	Opt-in. Re-send an unacknowledged alert every N minutes as a reminder during a long outage.	Off (per monitor)

Flap suppression

A monitor that bounces up and down repeatedly ("flapping") would otherwise storm your channels. HowlOps detects it and dampens the noise without hiding a real outage:

• If a monitor opens 5 or more alerts within a 10-minute window, it is marked flapping.
• While flapping, the broadcast to channels and the status-page updates are suppressed for a 30-minute cooldown, and a single "flapping" notice is posted instead.
• Escalation is deliberately not suppressed. A genuine sustained outage that begins during a flap window must still page on-call, so the escalation engine keeps running.

Quiet hours

Quiet hours hold non-critical notifications during a window you define (critical always pages). Enforcement differs by channel — this is intentional (a real page should wake you), but worth knowing:

Channel	During quiet hours (non-critical)
Chat (Slack / Discord / Telegram)	Dropped
SMS	Dropped
Email	Held for the daily digest (when the digest is enabled)
Mobile push	Dropped (suppressed during any active quiet-hours window, independent of the email digest)

Critical-severity alerts bypass quiet hours entirely. Escalation pages are treated as critical, so quiet hours effectively only mute warning/info broadcasts. There are two independent windows: a workspace-wide window (Settings → Notifications → Quiet hours) and an optional per-user window.

Grouping and suppression across monitors

Mechanism	Effect	Reduces pages?
Correlation	Alerts that fire close together are grouped into one view with an "N monitors affected" banner.	No — a display grouping only; each alert still fires.
Monitor dependencies	While a parent (upstream) monitor is down, alerts for the monitors that depend on it are suppressed.	Yes — child pages are withheld; the parent's outage already paged you.
Maintenance windows	During a scheduled window, alerts for the selected monitors are suppressed (checks still run).	Yes — for the window's duration.

To actually cut down the number of pages during a shared-cause outage, use monitor dependencies (see Monitors), not correlation.

Related

• Alert & incident flow
• Monitors
• Notifications
• When infrastructure fails