Incident communication timeline template: who you tell, when, and what you say

For small teams — 5 to 50 people — who have no communications department, a shared inbox, and an outage that customers will notice before you finish diagnosing it.

An outage does two kinds of damage at once. The technical damage is what the incident is about. The trust damage is what the silence is about. Customers forgive a broken checkout for an hour; they forgive a vendor who said nothing for an hour much more slowly, because silence reads as "they don't know" — and once a customer believes you don't know, every future update has to climb out of that hole. The fix is not eloquence. It is a schedule, written in daylight, that says who gets told what at which minute. This page is that schedule.

1. The rule that beats every template: tell them before they ask

The moment a customer has to ask what is wrong, you have already lost the update race — their next question is "what else don't you know?" So the timeline starts earlier than most teams think: the first update goes out before diagnosis is complete, sometimes before the cause is even guessed. "We know checkout is failing, we are on it, next update by 14:30" is a complete first update. It contains no diagnosis, and it does not need one. What it contains is proof of existence: someone is awake, the thing is owned, and there is a time when you will hear more.

2. Three audiences, three clocks

The internal audience is the one small teams forget, and it is the one that burns you: a support rep who learns about the outage from a customer tweet will improvise a promise ("it'll be fixed by 3, I'm sure") that engineering then has to honor or publicly walk back. Your staff are your widest communication channel — brief them first, and give them the same skeleton you give customers.

3. The timeline itself

Copy this table into the incident doc at declaration. Times are offsets from T0 = declaration (see the severity matrix for when declaration happens).

Two properties make this table survive contact with a real incident. First, every row names a person, not a role — "comms lead: Priya" written at T0, because "someone should update the status page" is how silence happens. Second, every update carries a next-update time — this is the single highest-leverage sentence in incident communications. "Next update by 14:30" converts your audience from refreshers into waiters, and it converts your obligation into a deadline the whole team can see.

4. The five-part update skeleton

Every update — first, middle, or final — has the same five slots. Fill them in order, keep it under a hundred words, and ship it on time even if slot 2 is "no change since last update."

1. Status line — one sentence: what is degraded, for whom. "Checkout is failing for about 30% of customers. Everything else works."
2. What we know — one or two sentences of fact, no speculation. "Errors began at 14:02. We have isolated it to the payment gateway."
3. What we're doing — present tense, no heroics. "We have engaged the gateway provider and are testing a fallback path."
4. Workaround — if one exists, it goes here, formatted as an instruction. "Invoices can still be paid via bank transfer; card checkout is affected."
5. Next update time — a clock time, not "shortly". "Next update by 14:30 or sooner."

Slot 5 is the one that ends "we're still working on it" as a genre. If you cannot make the next update time, the update that says you'll be late is itself an update — a 20-second "diagnosis is taking longer than planned; next update 15:00" preserves more trust than a silent twenty minutes past the promise.

5. The single-writer rule

All customer-facing words come from one comms lead per incident. Not the CEO, not whoever is angriest in the support inbox, not three people editing the status page concurrently. The comms lead collects facts from the incident channel, writes the update, and posts it on schedule. Everyone else — including executives — routes wording suggestions to the comms lead instead of posting their own. The reason is arithmetic: three writers means three versions of "what we know," and the audience will notice the differences and read them as concealment. If you have no spare person, the incident commander writes updates on a timer — a 30-minute alarm labeled "UPDATE" — rather than when the work pauses.

6. What never to write during an incident

• ETAs you invented. "Fixed in 20 minutes" becomes a promise with your name on it. Give a next-update time (which you control) instead of a next-fix time (which you don't).
• "Everything is fine." If customers can see the failure, this sentence costs you the next three updates' credibility.
• Names and blame. "A contractor misconfigured…" in a customer update is a career-shaped mistake and legally unwise. Causes, with blame stripped out, belong in the blameless review — published later, on purpose.
• Jargon and internal codenames. "p99 latency on the ingest path" means nothing to a shop owner whose card reader is down. Write the customer's sentence: "card payments are slow or failing."
• Speculation marked as fact. If the cause is unconfirmed, "we believe" or "we are testing whether" is the honest maximum.

7. Channels: pick one primary, keep it honest

The status page is the canonical home for updates; everything else points at it. But small teams should decide in daylight which channel is primary per audience: status page for self-serve customers, a direct email for the ten accounts that generate most revenue, a pinned Slack message for staff. During the incident, the comms lead updates the primary channel and lets the others mirror it — never the reverse. Mirroring from secondary channels is how two versions of the truth appear. If your primary is email, understand its latency (minutes, sometimes spam-folder minutes) and put the same text on the status page so the impatient can find it.

8. Worked example: twelve-person e-commerce SaaS, 47-minute gateway outage

At 14:02 card checkout started failing for shops using a specific payment gateway. The on-call engineer declared at 14:05 (severity 1), the comms lead was named in the same message, and the first customer update went out at 14:08 — four minutes after declaration, thirty-odd minutes before anyone knew the cause: "Checkout is failing for some shops. We're investigating with our payment provider. Bank-transfer invoices still work. Next update by 14:30." Updates followed at 14:30 ("gateway confirmed as the cause; we've engaged their escalation line — contact matrix did its job"), 14:49 ("traffic routed to fallback; card checkout recovering, some transactions may need retry"), and 14:55 ("confirmed resolved; we'll publish what happened within 72 hours"). Total customer-visible silence during the entire outage: zero. Support received no "what is happening?" tickets — the ones they did get were transaction-specific, which is support working as intended. The 72-hour post-mortem promise was kept on day two with a short summary and a link to the full review. One churn-risk customer replied to the final update: "first vendor that told me before I noticed."

9. Metrics that keep the timeline honest

• Time to first update — declaration to first customer-visible ack. Target under 15 minutes, every incident, no exceptions for "it was obvious quickly."
• Cadence kept % — promised next-update times met, divided by promises made. Below 90%, your update times have become aspirations and audiences start refreshing support inboxes instead.
• Post-mortem link published ≤72 h — the loop-closer. An outage whose story never gets published teaches customers that your updates end when the problem ends — which makes the next first update read as PR.

Where this fits

This timeline is the schedule; the words that go in the slots live next door: the status page communication template covers the page mechanics and message library, and the incident post-mortem template is the 72-hour follow-through this timeline promises. Declaration and severity live in the severity matrix; who gets paged to become the comms lead comes from the on-call escalation path. If the outage is vendor-caused, the vendor incident contacts one-pager is the difference between "we've engaged their escalation line" being true or wishful. For payments specifically, the payment outage playbook pairs diagnosis with this page's comms cadence.

If you want the communications layer built for you — message library, cadence rules, status-page copy, and the escalation wiring — that is exactly what Ops Starter Kit Vol. 2 covers in depth; the free First 30 Minutes quick-start gets the first update right today, and if you would rather have the whole timeline drafted from your actual stack, the Custom Incident Runbook ships it in 48 hours.

The timeline table this page mandates is also a data source: the incident metrics report computes cadence-kept % from these update timestamps and time-to-restore from the restore row.

The five-part update skeleton this timeline mandates is the body of every outage email — the templates simply pre-write it with the clocks attached.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — full incident-response kit for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $29
• Custom Incident Runbook — done-for-you, built from your estate, 48h — $249