Glossary
Incident
An incident is an unplanned disruption to a service, tracked as a single record from detection through to resolution.
An incident is the record of an unplanned disruption. It exists to be the single thing everyone refers to during a bad hour: one identifier, one timeline, one place where the current understanding lives. Without it, a multi-service failure becomes several parallel conversations that each discover the same facts separately.
It is a state machine rather than a ticket. An incident is created, acknowledged when a person takes it, may pass through investigating and identified as understanding improves, and is finally resolved. Each transition is timestamped, and those timestamps are what later produce the response metrics — time to detect, time to acknowledge, time to resolve — without anybody having to reconstruct them from memory.
An incident is deliberately not the same as an alert. Alerts are signals, and a single incident usually collects many of them: the database failing produces alerts from every service that depends on it. Grouping them into one incident is what keeps a large failure to one conversation and one page rather than fifteen.
Nor is it a bug report. An incident ends when customer impact ends, which is often before anyone knows the cause — a restart or a rollback resolves it while the underlying defect is still entirely mysterious. That understanding belongs in the investigation afterwards; keeping the two separate stops incidents staying open for weeks and stops the real fix being forgotten once the pressure lifts.
| Stage | What happens | Metric it ends |
|---|---|---|
| Detected | A monitor, an alert or a customer report shows something is wrong, and the incident is opened. | MTTD, time to detect |
| Acknowledged | A person takes ownership, so everyone else knows it is being handled. | MTTA, time to acknowledge |
| Investigating | The responder works out what is broken and how to stop the impact. | None; usually the longest stage |
| Resolved | Customer impact has ended, often by a rollback or restart before the cause is known. | MTTR, time to resolve |
| Postmortem | The team writes down what happened and what will change. | None; it happens after the incident |
Questions
What is an incident?
An incident is an unplanned disruption to a service that customers can feel, tracked as one record with one timeline from the moment it is detected until the impact ends.
What is the difference between an incident and an alert?
An alert is a signal that a condition was met, such as a failed check. An incident is the tracked disruption, and one incident usually collects many alerts: a failing database raises an alert from every service that depends on it, and all of them belong to one incident.
What is the difference between an incident and a problem?
In ITIL terms, an incident is the disruption and ends when service is restored. A problem is the underlying cause, and it stays open until that cause is found and fixed. One problem can sit behind many incidents.
What is an example of an incident?
A checkout page returning 500 errors after a deploy, an expired TLS certificate that stops browsers loading the site, a database that runs out of disk, or a DNS change that sends traffic to the wrong place. Each disrupts customers and each ends when service is restored.
Who declares an incident?
Anyone who sees customer impact should be able to, and monitoring often does it first. A clear rule for who may declare, and a low bar for doing so, costs less than an outage nobody opened because nobody was sure it counted.
In Uptimely
Uptimely creates an incident automatically when a monitor's criteria are met and the failure threshold is crossed, or by hand for anything monitoring did not see. Each incident carries its own state timeline, its affected resources, its on-call policy and its public notes, and incidents opening close together are grouped into a single episode.
Uptimely declares incidents from your monitors automatically, after 2 consecutive failed checks by default, and keeps each one's timeline from detection to resolution.
Start monitoring free →Read next
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.