Skip to content

War rooms & incidents

An incident in DXDT is a tracked operational event with a severity (SEV1–SEV4), a commander, and a timeline that records everything — human messages, agent investigations, status changes, linked findings — in order, permanently.

Creating incidents

  • Manually from the Incidents page or dxdt incidents in the CLI.
  • Automatically from triage: high-severity events can open incidents on their own (Team page → Incident Management → Auto-Escalation, with a severity threshold).
  • From Pulse: critical findings can escalate into incidents with the finding's evidence attached.

The war room

Opening a war room on an incident gives the response a shared surface: the timeline, the responders, and the DXDT agent working alongside — investigating, correlating against the dependency graph, and citing your institutional memory where it applies ("per dana, Sunday failovers are expected — this one is Tuesday").

Where a Slack workspace is connected, war rooms can mirror into a dedicated Slack channel so responders who live in Slack never leave it.

Resolution and the record

Set the incident to resolved when it's over — the resolved timestamp is what drives your MTTR metrics, and the closed incident joins your searchable history. Six months in, "what happened last time Cloud SQL failed over?" is a question DXDT answers from your incidents, not general knowledge.

The flight recorder

Resolving an incident automatically drafts a blameless postmortem from the recorded timeline — summary, highlights, contributing factors, action items, and, importantly, gaps in the record (what the timeline doesn't show is stated, never guessed). The draft is posted into the timeline marked as a draft for your review; you can also generate one on demand with Draft postmortem in the war-room sidebar. Everything in the draft traces to a recorded entry — DXDT writes the first 80%, your team writes the judgment.

Postmortem replays

A war room whose title starts with [Replay] is a reconstruction, not a live event: DXDT takes a past incident's postmortem and interleaves the original timeline with what it would have contributed at each minute, grounded strictly in your currently connected integrations — including honest gaps ("with your current integrations DXDT could not see X"). Replays are marked as such on every entry and never mix into your real incident history or metrics.

Best practices

  • Open incidents liberally, resolve them honestly. The record is the asset; an incident that was "handled in DMs" teaches DXDT nothing.
  • Let the timeline be the postmortem. A well-kept war room timeline is 80% of the writeup already.
  • Severity discipline. SEV1 should page people. If everything is SEV2, nothing is.