A failed request starts the investigation. Put regional results, confirmation rules, and incident history in front of your team before the first alert becomes a search for context.
Checks, decisions, and delivery in one chronology.
Fictional evidence · No live requests are made by this preview
01 / Signal confirmation
One region is a signal. Agreement changes the response.
Explore three fictional snapshots of the same HTTP monitor. Watch how persistence, regional agreement, and verified recovery change the incident state.
Regional check results
RegionResponseEvidence
VirginiaHTTP 5032 failures
FrankfurtHTTP 200Healthy
OregonHTTP 200Healthy
Confirmation rule not met. No confirmed-incident notification.
Incident decisionInvestigating
1 of 3
regions at the failure threshold
One region fails. Keep investigating.
Virginia reports repeated failures, but Frankfurt and Oregon still respond. This example requires two regions to meet the failure threshold before confirming an outage.
Example policy
Failure
2 checks
Quorum
2 regions
Recovery
2 successes
Interval
1 minute · Pro
02 / Response controls
Define what deserves an interruption.
Set the rules around the service you operate. Keep transient failures and expected downtime in context.
Configure consecutive-failure thresholds so a transient request failure becomes evidence to investigate before it becomes a confirmed outage.
Example failure rule2 consecutive failures
Look for agreement.
Use independent locations to establish whether a service failure meets your regional confirmation rule.
Example regional quorum2 of 3 regions
Account for planned work.
Use maintenance windows and monitor mute controls to manage expected downtime and intentional interruptions.
Keep expected downtime in contextScheduled maintenance
03 / Connected response
Send the event. Keep the context.
Use Slack for team visibility, email for direct notifications, or signed webhooks for your own incident tooling. Choose confirmed outages, recoveries, or both.