> Markdown version of https://getuptimely.com/glossary/incident — the page itself is the canonical copy. 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. __The stages most incident processes share, and the response metric each one ends.__ | 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 →](https://app.getuptimely.com/accounts/register) ## Read next - [Incidents and alerts](https://getuptimely.com/docs/incidents-and-alerts) ## Related terms - [Alert](https://getuptimely.com/glossary/alert) - [Incident severity](https://getuptimely.com/glossary/incident-severity) - [Acknowledgement](https://getuptimely.com/glossary/acknowledgement) - [Postmortem](https://getuptimely.com/glossary/postmortem) - [Root cause analysis](https://getuptimely.com/glossary/root-cause-analysis) - [Mean time to recovery (MTTR)](https://getuptimely.com/glossary/mttr) Part of the [Uptimely monitoring glossary](https://getuptimely.com/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**.