📣 Freeing the Incident Commander With AI Status Comms

Forty minutes into the incident, the IC was doing everything except running the incident. Leadership wanted a summary. The status page was stale and customers were tweeting. Support needed a script. So the one person whose job was to keep the investigation moving spent the next ten minutes writing four different versions of “we’re aware and working on it” for four different audiences — and the investigation drifted, because its conductor had put down the baton to write copy. Status communications don’t show up on the MTTR timeline as a diagnosis step, but every minute the IC spends writing is a minute nobody is coordinating.

Drafting the same facts for different audiences is bounded, repetitive writing under tone constraints — which is exactly what a model does well. Hand it the incident state and it returns the internal update, the exec summary, the status-page post, and the support script, all at once, for the IC to review and send.

The IC’s attention is the bottleneck

The incident commander’s scarcest resource is undivided attention, and comms are one of its biggest drains. Each context-switch from coordinating to composing has a cost beyond the minutes spent: it breaks the IC’s thread on the actual incident. Removing the blank-page tax keeps the IC on the work that shrinks MTTR — the same “remove the avoidable friction” principle that runs through the MTTR category.

A model can’t run the incident, but it can absolutely turn one statement of state into four audience-appropriate drafts, which is the part that’s tedious rather than judgment-heavy.

Ask for every audience from one statement of state

The framing tailors tone and guards the public surface.

You are drafting incident status updates from this state, not deciding strategy. Produce four drafts: (1) internal channel — terse, technical, what changed since last update, who owns what; (2) leadership — business impact, severity, what’s being done, any decision needed, no jargon; (3) public status page — calm, honest, no internal detail, no speculation, ETA only if I gave you one; (4) support — what to tell customers, what to escalate. Mark any claim that needs my sign-off before publishing. Do not invent a cause or an ETA.

The drafts come back ready to review:

Internal: Checkout p99 4x since 14:07, steady. Suspect orders-api v4.2; Sam confirming heavy query. Rollback pre-staged. Next update 15m. Leadership: Some customers seeing slow checkout (~15 min). Severity 2, not worsening. Team has a likely cause and a tested rollback ready. No decision needed yet. Public: We’re investigating reports of slow checkout performance. Some customers may experience delays completing orders. We’re actively working on it and will update shortly. Support: Tell affected customers we’re aware of slow checkout and working on it; no data is at risk. Escalate any report of failed payments. ⚠ Sign-off needed: the “likely cause” line for leadership — confirm before sending.

Ten minutes of writing becomes a one-minute review across four surfaces.

Guard the public surface hardest

# Reconcile the draft against live state before sending — is it still steady?
curl -s "http://prom:9090/api/v1/query?query=\
histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket\
{service=\"checkout\"}[1m]))by(le))" | jq -r '.data.result[].value[1]'

The public status page is where AI’s helpfulness becomes a liability. A model trying to be useful will volunteer a cause (“a database issue”) or an ETA (“resolved within the hour”), and once that’s published it’s a commitment you may not keep. So the prompt forbids speculating on cause or timeline in customer-facing copy unless the human supplied it, and flags anything publishable for sign-off. The internal channel can carry the hypothesis; the public page carries only confirmed impact.

Draft fast, review every word

The line: the model drafts, the human publishes. Comms drafting must never run on autopilot, because the drafts are only as current as the state you pasted — a stale input produces a confident misrepresentation on a public page.

Rules I hold to:

• Reconcile against live state before sending. “Steady” written two minutes ago is wrong if it just got worse; the IC verifies before publishing.
• No cause or ETA in public copy without confirmation. Internal speculation is fine and useful; public speculation is a liability.
• Treat each update as a delta. Feeding the model the last update keeps the new one focused on what changed, not a re-statement.

You can practice this on the free incident assistant — paste an incident state and ask for the four audience drafts, then notice how much faster a review-and-send loop is than writing each from scratch. The prompt library has a hardened status-comms prompt with the public-surface guardrails built in.

The IC’s attention is the resource that moves an incident toward resolution, and every minute spent writing status copy is a minute it isn’t spent coordinating. AI removes the blank-page tax by drafting every audience at once — and as long as the human reviews every word and never lets a speculated cause reach a public page, the commander stays on the work that actually cuts MTTR.