The 6 Incident Messages Every Team Should Have Pre-Written

At 2:40 AM everything is on fire. Your users know it, your manager knows it, and your group chat has gone quiet because everyone is waiting for you to say something.

Most small teams handle this badly — not because they can't fix the incident, but because they improvise the communication. Every message is written from scratch under adrenaline, and every improvised message is worse than it needs to be.

The fix costs almost nothing: write your incident messages now, while nothing is burning, and keep them in a doc everyone can reach. Here are the six messages your team should have on file.

1. The "we know" message (send within 15 minutes)

The first message isn't about the fix. It exists to stop the DMs.

[INCIDENT — Investigating] We are aware of reports that is . The on-call engineer is investigating. Next update by HH:MM or sooner.

Three parts: what's broken, who has it, when the next update lands. If you only remember one thing: always promise a next-update time, then keep it — even if the update is "no change."

2. The internal bridge kickoff (for your own team)

Bridge: #incident- — status: Investigating. IC: . Scribe: . Timeline doc: . Non-ICs: please don't DM the on-call; put findings in the channel.

Rotating the IC and scribe roles in the template prevents the classic failure where one exhausted person is simultaneously fixing, explaining, and writing history.

3. The identified update

[INCIDENT — Identified] Cause identified: . We're applying the fix now. ETA for next update: HH:MM.

One sentence of cause. Resist the urge to explain the whole system. People just want to know it's understood and being worked.

4. The "no change" update (the one everyone skips)

[INCIDENT — Update HH:MM] No change since the last update. Engineering is still actively working. Next update: HH:MM.

Silence is the most expensive thing you can publish during an incident. Users fill silence with worst-case assumptions and support tickets. A "no change" message costs ten seconds and kills both.

5. The mitigation message

[INCIDENT — Mitigating] A fix has been applied and we're monitoring recovery. Services should be within minutes. We'll confirm with an all-clear.

"Mitigating" is honest: you think you fixed it, and you haven't watched it prove that yet. Skip the word "resolved" until data backs it.

6. The all-clear (with a follow-up promise)

[RESOLVED — HH:MM] is operating normally. The incident lasted minutes. A short post-mortem with root cause will be published within <2> business days.

The follow-up promise is what separates teams that recover trust from teams that don't. Publish the post-mortem, even if it's five lines.

---

The pattern: each message is four things — status, fact, action, next-update time. Nothing else. Your users don't want a narrative; they want to know it's known, it's being worked, and when to look again.

Copy these into your on-call doc, delete what doesn't fit, and rehearse them once in your next game day. The night of the incident is the worst possible time to write well.

Incident Response Resources

Want a full playbook?

✅ Free Sample Checklist (The First 30 Minutes): https://hive80lab.gumroad.com/l/rtodsv

📚 Ops Field Cards (12 printable incident checklists, $4): https://hive80lab.gumroad.com/l/rtodsv

📝 Small-Team Ops Audit ($149, 5-day delivery, prioritized findings): https://hive80lab.gumroad.com/l/ljogci

These include the six comms templates above, escalation ladders, containment checklists for Linux/macOS/Windows, and five tabletop exercises (ransomware, BEC, insider, lost laptop, exfiltration).

Tags: incident-response, ransomware, it-operations, small-business, cybersecurity, devops, sre