Opened and closed automatically
Confirmed failures open an incident; confirmed recoveries close it. Nobody has to remember to update the status page while they’re busy fixing the actual problem.
Incident Management
Incidents that write their own first update.
A confirmed failure opens an incident with the facts already in it: what, since when, and from where. You add the human part. Recovery closes it.
Free plan, no card needed.
Incident · INC-0418
Elevated checkout latency
- Investigating 09:12 · Automatic
Checkout Service degraded: p95 512 ms over the 400 ms threshold. Confirmed from N. Virginia and Frankfurt.
- Identified 09:19 · Mira
Slow query on the orders table after this morning’s migration. Rolling back the index change.
- Monitoring 09:31 · Mira
Rollback complete. p95 back under 150 ms from all regions; watching for 20 minutes.
- Resolved 09:52 · Automatic
Checkout Service recovered. Total duration 40 minutes.
Posted to status.acme.com · 214 subscribers notified 4 updates
Incident Management, in detail.
The states people expect
Investigating, Identified, Monitoring and Resolved, with templates for the updates you end up writing over and over. Optional postmortems publish alongside the incident.
Manual incidents too
For what monitors can’t see: a partner outage, a data issue, a bad deploy caught by hand. Same timeline, same subscriber updates.
Maintenance that doesn’t cry wolf
Scheduled windows notify subscribers, silence alerts for the duration, and are excluded from uptime history, so planned work doesn’t look like downtime.
status.acme.com
A Acme
Subscribe Partial degradation
Checkout is slower than usual. Investigating · updated 4 min ago
- API99.98% Up
- Web app100% Up
- Checkout99.71% Degraded
- Email delivery99.95% Up
90 days ago Today
Works with
Every part of StatusCheck is on every plan. These are the pieces this one talks to most.
Try it on your own endpoints.
The free plan needs no card. Add a monitor, pick the regions, and see the first check in under a minute.