# Incidents

An unplanned disruption or degradation of service.

Source: https://statusdashboard.com/docs/events/types/incident

Use an incident when an unplanned disruption or degradation affects one or more services. Incidents require a start time, affected components with severity, and a public timeline that drives resolution and end time on your status dashboards.

***

## Times
An incident represents an unplanned disruption or degradation of service. Incidents:

* Require a **start time** — set when you create the incident and can be backdated
* Require at least one **affected component** with a severity assigned
* Have their **severity auto-derived** from the highest-severity affected component
* Drive an **incident workflow** lifecycle (e.g. Investigating → Identified → Monitoring → Resolved)
* Track a **public timeline** of status updates visible on the status dashboard

| Time           | How it's set                                                                                                         |
| -------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Start time** | You provide it at creation (required). Can be backdated to when the incident actually began.                         |
| **End time**   | Automatically set to the timestamp of the final timeline entry (e.g. "Resolved"). Can be overridden via direct edit. |

The first timeline entry's timestamp is always synced to the incident's start time — they are the same value when the incident is created.

On the **Description** tab, you can optionally add **Impact Analysis** after the description. When set, it appears on status dashboard event cards and in full subscriber notifications (after the description, before affected components).

> Backdating the start time is encouraged for SLA accuracy. If a customer reported an issue 30 minutes before you opened the incident, set the start time to when the incident actually began — not when you created the record.