01
Repeated failures
Configure consecutive-failure thresholds so one noisy check does not immediately become a confirmed outage.
Example failure threshold2 consecutive failures
Product / Incident management
From first signal
to a clear response.
Confirm the failure. Give the response an owner. Keep your team and customers informed, with every decision connected to the same incident.
10 monitors free No credit card required
Evidence before escalationOne connected record
HTTP monitor
Checkout API
Elevated checkout errors across two regions.
Regional check results
09:42:12 UTC- Virginia
HTTP 503Failed twice - Frankfurt
HTTP 503Failed twice - Oregon
HTTP 200Passing
2 of 3 regions meet the confirmation rule.
01 / Confirm
Make the alert
mean something.
An investigation collects evidence. Your configured thresholds determine when it becomes a confirmed outage and the team should be notified.
See how regional confirmation works02
Regional agreement
Require independent regions to agree before confirming the incident.
Example confirmation rule2 of 3 regions
03
Planned maintenance
Keep expected downtime separate with maintenance windows and monitor mute controls.
Separate planned workMaintenance windows
One failed check starts the investigation. The confirmation policy decides what happens next.
02 / Coordinate
A shared record.
A clear next step.
Acknowledge the incident, assign a responder, and set severity. Keep investigation notes beside the checks that explain the failure.
Learn the response workflowOne timeline. The full context.
Incident activityInvestigation opened
Virginia and Frankfurt return HTTP 503. One failed check starts an investigation; the team has not been alerted yet.
Outage confirmedPolicy met
Both regions fail their next check. Two consecutive failures in two of three regions meet this monitor’s confirmation rules.
Team notified
Email and Slack delivery succeed. The alert includes the affected monitor and regional evidence.
Customer update published
An operator publishes a public update: “We are investigating errors affecting checkout. Our team is working to restore service.”
MC
Maya ChenInternal note
Comparing the failed checks with recent deployments. Oregon is still responding normally.
03 / Communicate
One incident.
The right context for everyone.
Give responders the operational details and customers a clear public update. Keep both connected to the incident.
For your teamInternal
Know what was delivered.
Inspect notification attempts and outcomes. A delivery failure stays distinct from the outage itself.
Notification historyINC-1042
EmailOutage notification
Delivered
SlackOutage notification
Delivered
Illustrative delivery history
Explore notification integrationsFor your customersPublic
Keep customers informed.
Publish status-page updates while keeping internal notes and monitor targets private.
Acme CloudService updates
Investigating
Investigating checkout errors
We are investigating errors affecting checkout. Our team is working to restore service.
Example public update · Published by an operator
View the example status pageInternal investigation notes stay with your team. You choose what to publish.
04 / Resolve
Recovery is part
of the record.
Resolve through configured recovery thresholds or a responder action. Preserve the timeline and resolution summary so the next review starts with evidence.
- Recovery evidence and resolution time
- Responder actions and investigation notes
- Customer updates and delivery history
Checkout API
Recovered. Recorded.
Successful checks
Recovery verified
Incident resolved
Example recovery threshold2 consecutive successful checks
Ready for the review
The resolution closes the incident. The evidence, team activity, and customer communication remain in its history.
The complete response stays available.
Be ready for the next signal
Bring clarity to your response.
Start monitoring for free, with incident context built in.