An alert tells you something is wrong. Then the real work starts: is it really down, what does the error look like, who is handling it, have customers been told, and what do we change so it does not happen again? Many teams answer those questions across three tools and a long chat thread. Uptimecheck keeps the answers with the incident.
Confirmed outages
Uptimecheck checks from Stockholm, Sweden, and confirms every failure with a second check before an incident opens. A single dropped request never wakes anyone. When the outage is real, the incident opens, alerts go out and the timeline starts. It closes by itself when the monitor recovers. Our guide to reducing false alerts explains why confirmation matters.
Evidence attached
- What we saw: the failing check, with the address it connected to, the headers and the start of the response.
- Network path: when the server did not answer, a traceroute from the checking location shows where the path breaks.
- Screenshot: when the server did answer, a real browser photographs what visitors saw. Screenshots are kept for 90 days.
That is often enough to tell a dead server from a broken deploy, or your problem from your hosting provider’s, before anyone has logged in.
One timeline
The incident timeline shows the checks, every alert and who it reached, acknowledgements and notes, in order. Acknowledge tells the team someone is on it and cancels delayed alerts that have not gone out yet. In Slack, the Acknowledge button on the outage alert does the same without opening the app. Notes are for your team only.
- 03:12: checkout.northwind.shop returns 503, confirmed by a second check. The response and a screenshot are attached.
- 03:13: push notification to Anna, who is on call.
- 03:15: acknowledged in Slack.
- 03:19: recovered after 7 minutes. A recovery notice goes out.
Escalation and on-call
A channel can wait 5 to 60 minutes and only alert if the outage is still going and nobody has acknowledged it. Post to Slack right away, and push to whoever is on call after 10 minutes. On-call schedules decide who that is, and alerts and notifications covers every channel.
MTTA and MTTR
The incidents page shows the mean time to acknowledge (MTTA) and the mean time to resolve (MTTR) over the last 30 days. Together they tell you whether alerts reach people who can act, and how quickly problems get fixed. Our article on MTTR, MTTA and MTBF explains how to read them.
Incident reviews
After an incident, write a short review: what happened, why, and what you are changing. Keep it for the team, or show it under the incident on your status page. Customers trust a page that explains outages more than one that never has any. Our incident postmortem template gives you a structure to start from.
Maintenance windows
Planned work should not page anyone. During a maintenance window, the chosen monitors are not checked, no incidents open, no alerts go out and the time does not count against uptime. Windows can be one-off or repeat daily, weekly or monthly; they are shown on status pages and can be emailed to subscribers. Start one from your deploy script through the REST API.
Open an incident with its timeline in the live demo, no account needed. Incident management is included on every plan.
Plans start at €9 per month billed yearly or €12 billed monthly, excl. VAT. See the pricing page, or start a 14-day free trial without a card.