Incident response: declare fast, timeline everything, postmortem with data

# Incident response workflow in Datadog

## Declare fast

Declare from wherever you are: the alert that fired, a dashboard graph widget, the Incidents UI, or Slack with `/datadog incident`. The declaration needs three things: a descriptive title, a severity (SEV-1 most severe to SEV-5 least, customizable), and an incident commander. Fill all three at declaration; "we will assign a commander later" is how incidents drift.

## Run it

1. **Commander owns the incident**, not the fix. Their job is coordination, timeline, and comms. The best engineer on the fix is not the commander.
2. **Timeline everything**: detection, actions, comms. The timeline is the postmortem draft and the legal record. Slack integration can mirror thread replies into the timeline.
3. **Page from the incident**: the On-Call integration pages teams directly from the incident, manually or automatically. Escalate the page into the incident rather than running a parallel thread.
4. **Status pages**: connect incidents to status pages for customer comms. One source of truth beats five Slack threads.

## After

- **Postmortem in notebooks**: draft and review the postmortem where the data lives. The incident analytics (time to resolution, customer impact) feed the review with numbers, not vibes.
- **Action items with owners**: every postmortem ends with dated, owned actions. "Improve monitoring" is not an action item.
- **Severity calibration**: if everything is SEV-2, the scale is broken. Review severity distribution quarterly.

## Verify

Run a game day: declare a test incident, page the on-call from it, confirm the timeline captures the Slack thread, and write the postmortem. The workflow you have not rehearsed is the workflow that fails at 3am.