Glossary · Incidents and alerting
An incident is an unplanned event that interrupts a service or reduces its quality, such as an outage, errors or responses too slow to use, and needs a response to restore normal service.
Incident management is the work from detection to resolution: confirm the problem, alert the right people, decide who leads, tell users, restore service, then learn from it in a postmortem. Severity levels, often SEV1 to SEV3 or P1 to P4, decide how big the response is.
An incident is not the same as its cause. One root cause, like a failing database, can produce many symptoms; a good process groups them, so the team works on one incident, not twenty alerts.
Communication is part of the work. A status page update within minutes, and more at a set rhythm, saves the support team from answering the same question many times.
In Uptimecheck an incident opens when a second check confirms a failure and closes by itself when the monitor recovers. It holds a timeline of checks, alerts, acknowledgements and team notes, and the evidence from when it opened. Acknowledge it to show the team someone is on it and to cancel escalation alerts that haven’t gone out yet.
14-day free trial · No credit card required
Guides 5 min read
How to tell customers about an outage: who speaks, how often, on which channel and in what words. A one-page plan, severity levels, update cadence and ready-to-use templates for status pages, email and social media.
ReadGuides 6 min read
A copy-ready incident postmortem template, the blameless principles behind it, a filled-in example from a checkout outage and how to publish a short summary on your status page.
ReadGuides 6 min read
MTTR, MTTA and MTBF measure how fast you fix incidents, how fast you respond and how often things break. Formulas, a worked example and practical ways to improve each one.
ReadIn ITIL terms, an incident is the interruption and a problem is the underlying cause of one or more incidents. Incident management restores service; problem management stops it from happening again.
A scale of how bad an incident is, usually from SEV1 (a full outage for many users) to SEV3 or SEV4 (minor or internal). The level decides who is paged, how often updates go out and whether a postmortem is required.
The person on call first, then the team that owns the service, and affected users through a status page once you know what is affected. Update them at a set rhythm, even when there is nothing new.
Set up your first monitor in under a minute, or look around the live demo first.
14-day free trial · No credit card required
With your OK, Google Analytics and Microsoft Clarity show us which pages help and where visitors get stuck. They set cookies for up to 13 months. Without your OK, neither of them runs. You can change your mind at any time under Cookie settings at the bottom of the page. Privacy policy