Require persistence
Configure consecutive-failure thresholds for each monitor. Treat a transient failure as evidence to investigate before confirming an outage.
All solutions Less guesswork.
Undown for DevOps
Less guesswork.
More evidence
at the first alert.
A failed request is the start of an investigation. Bring regional results, confirmation rules and incident history into view before your team starts piecing the story together.
10 monitors free · No credit card required
incident / INC-1042Example evidence
api.example.com/health
Confirmed outage09:41:08CHECK
Virginia returned HTTP 503
09:42:12CONFIRM
2 consecutive failures / 2 regions
09:42:14NOTIFY
Slack delivery succeeded
A record you can investigate.
Check results, regional context and delivery history alongside the incident.
Inspect the confirmation model
A local failure isn't
the whole picture.
Explore three fictional snapshots of an HTTP monitor. The example uses one-minute Pro checks, two consecutive failures, a two-region quorum, and two consecutive successes for recovery.
HTTP monitor · Example times UTCInvestigating
RegionLatest resultEvidence
VirginiaHTTP 5032 failures
FrankfurtHTTP 200Healthy
OregonHTTP 200Healthy
Confirmation rule not met. No confirmed-incident notification.
09:41:12 UTC
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.
Controls with a purpose
Define what deserves
an interruption.
Look for regional agreement
Use independent locations to establish whether a service failure meets your regional confirmation rules.
Account for planned work
Use maintenance windows and monitor mute controls to manage expected downtime and intentional interruptions.
Fit the response you already run
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 when configuring a destination.
Explore integrationsExample response destinations
Slack
Put confirmed incidents in the team channel.
Notify the people who need to respond.
Signed webhooks
Verify event payloads in your own application.
Review delivery outcomes and retry history when an alert does not arrive as expected.
Beyond the first alert
Leave the next responder
a clearer record.
Keep the chronology close
Review check observations and incident transitions to understand when the failure started, when it was confirmed, and what supported recovery.
Separate evidence from public updates
Keep technical investigation in the workspace. Publish a clear explanation on a status page when customers need to know what is affected.
See the customer viewStart with a production endpoint
Make the next alert
a better starting point.
Add a monitor, configure confirmation, and connect your response tools.
Create your free workspace
10 monitors free · No credit card required