Alert Sensitivity: Conservative vs Sensitive
Last updated: 2026-05-04
Every monitor has an Alert Sensitivity setting that controls how much confirmation is required before an alert fires. You can find it in the Alerts & Incident Behavior section of the monitor edit page.
The two modes
Conservative (default)
A majority of your configured monitoring regions must independently report the service as DOWN within a short window before an alert is sent.
- Fewer false positives — a single region experiencing a local network glitch, a routing anomaly, or a brief ISP hiccup will not wake anyone up
- Slightly slower to alert — the system waits for confirmation from other regions before acting
- Best for: most services, teams sensitive to alert fatigue, monitors on less critical infrastructure
Sensitive
Any single region reporting DOWN immediately triggers an alert, without waiting for other regions to confirm.
- Fastest possible detection — the alert fires as soon as the first failure is recorded
- Higher chance of false positives — an isolated network issue in one region will alert even if the service is fully reachable everywhere else
- Best for: payment systems, APIs with strict SLAs, services where every second of undetected downtime has business impact
How to change it
- Go to Monitors and expand the monitor row, then click Edit — or open the monitor’s Edit page directly
- Scroll to Alerts & Incident Behavior
- Toggle Alert Sensitivity: Sensitive on or off
- Click Update Monitor
The change takes effect on the next check cycle — no restart required.
What changes under the hood
Conservative uses quorum confirmation: the number of regions that must agree on DOWN is calculated as a majority of your configured locations (floor(N/2)+1 with a primary, or ceil(N/2) in peer mode).
Sensitive overrides that threshold to 1 — the first region to report DOWN is sufficient to trigger the full alert and incident workflow, identical to what would happen after quorum in Conservative mode.
No other behaviour changes: alerts, incidents, notifications, and recovery detection all work exactly the same way in both modes.
Improved detection for all monitors
Alongside the Alert Sensitivity setting, a pair of reliability improvements now apply to every monitor regardless of sensitivity mode:
Ongoing-outage confirmation bursts
Previously, secondary regions were only asked to confirm a failure at the moment a monitor first flipped to DOWN. During a prolonged outage, only the primary region continued checking. Now, secondary regions receive a new confirmation request every 45 seconds throughout an ongoing outage — keeping multi-region validation active for the full duration and making recovery detection faster.
Wider confirmation window
Secondary agents now have 45 seconds to pick up and run their confirmation check (previously 20 seconds), and the quorum evaluation window has been widened from 20 to 30 seconds. This reduces missed confirmations caused by slow agent pickup times, which previously caused some DOWN events to appear with fewer regions than expected in Check History.
Choosing the right mode
| Situation | Recommended mode |
|---|---|
| General-purpose website or API | Conservative |
| Payment processor or checkout flow | Sensitive |
| Internal tooling or staging environment | Conservative |
| Public-facing API with strict SLA | Sensitive |
| Monitor with many regions in diverse networks | Conservative |
| Single-region or primary-only monitor | Either (quorum threshold is 1 either way) |
When in doubt, start with Conservative. You can always switch to Sensitive later if you find you are missing brief outages that matter to your users.