Incident Communication: Templates and a Cadence

Incident communication is the work of telling people a service is broken before they have to ask. It is mostly a writing problem with a timing constraint. The first public update decides whether the next hour is spent fixing the fault or answering the same question in twelve support tickets.

What an incident communication plan actually covers

A plan names four audiences and one owner for each. Customers need to know whether their work is affected. Internal responders need a single place to coordinate. Support needs a line they can paste. Executives need to know the blast radius without joining the call.

Most plans fail on the second of those. Atlassian's guide describes the practice as alerting users that a service is degraded or down, which is the customer half. The internal half is what stops three people from writing three different versions of the same sentence.

Write the plan as a table before you write any templates. Each row is an audience, a channel, an owner and a trigger.

Audience	Channel	Who posts	Trigger
Customers	Public status page	Incident commander	Second region confirms the failure
Responders	One chat channel per incident	Whoever acknowledged the alert	First page
Support	Pinned message with a paste-ready line	Comms lead	Within 5 minutes of the public post
Leadership	Summary thread, no live debugging	Comms lead	Severity 1 only

Who posts the first update, and when?

The person who acknowledges the alert posts the first update, and it goes out before the cause is known. That is the part teams resist. An update that says "we are investigating elevated errors on checkout" is useful even when you have nothing else, because it converts an unknown outage into a known one.

Tie the trigger to a monitor state rather than to a human judgement call. A single failed check is a blip. A failure confirmed from a second probe region is an incident, and that is the moment the status page should change. Waiting for a diagnosis instead means the first update lands forty minutes late, which is when the support queue has already filled up.

Incident.io's January 2026 write-up makes the same argument from the other end: automating the status update is what stops the "is it down" tickets. We prefer to draft the investigating message in advance so nobody has to compose one under pressure.

Templates for each phase

Three templates cover almost every incident. Keep them short, keep the tense present, and never speculate about a cause in public.

INVESTIGATING
We are investigating reports of <symptom> affecting <component>.
Customers may see <user-visible effect>.
Next update by <time + 30 minutes>.

IDENTIFIED
We have identified the cause of <symptom> on <component> and
are applying a fix. <Workaround, if one exists.>
Next update by <time + 30 minutes>.

RESOLVED
<Component> has been operating normally since <time, with timezone>.
The incident lasted <duration>. A full write-up follows within
<n> business days.

The Next update by line is the one that does the heavy lifting. It converts an open-ended wait into an appointment, and it is the difference between a customer refreshing every two minutes and one closing the tab. Missing a promised update costs more trust than the outage did.

Avoid words that sound reassuring and mean nothing. "Some users may experience intermittent issues" tells a reader nothing they can act on. "Checkout is failing for card payments; bank transfer still works" tells them exactly what to do next.

Setting the cadence by severity

Cadence is the part of incident communication that teams over-promise. Set it low enough that you can keep it while also fixing the problem. A thirty-minute rhythm on a severity 1 is sustainable. A ten-minute rhythm is not, and breaking it looks worse than never having offered it.

Severity	Example	First update	Cadence	Channels
Sev 1	Checkout down for everyone	Within 10 minutes	Every 30 minutes	Status page, email subscribers, support
Sev 2	One region degraded	Within 30 minutes	Every 60 minutes	Status page, support
Sev 3	Background job delayed	Same business day	On resolution	Status page only

Publish the cadence on the status page itself. A reader who knows updates arrive every thirty minutes does not need to email you at minute twelve.

Wiring the status page to the monitors

Incident communication gets faster when the trigger is mechanical. Model the status page on what customers buy rather than on your services. A component called "Checkout" is meaningful. A component called "payments-worker-3" is not, and it leaks architecture nobody outside asked for.

Each status page lives at /status/<slug> and carries components, incidents, maintenance windows, subscriber emails and an RSS feed. Status pages and their components are configured in the dashboard rather than over the REST API, which today covers monitors, incidents, channels and the knowledge hub. Build the component list first, then attach the monitors that already exist.

A workable first page for a small SaaS is three components and no more. Checkout, API and Dashboard each map onto one or two monitors, and every extra component is another row a customer has to read during an outage. You can confirm which monitors are available to attach with a single call.

curl -s https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..."

Subscriber emails matter more than the page itself. Most customers never visit a status page during an outage; they find out from the email, or they do not find out at all. Field definitions for the remaining options are in the REST API reference.

Planned work belongs on the same page, scheduled ahead of time so it never becomes an incident. That mechanism is covered separately in maintenance windows.

Internal updates are a different job

The internal thread is not a draft of the public one. Responders need timestamps, hypotheses and dead ends, and they need them in a place that survives the incident. Customers need none of that. Mixing the two produces a public post full of hedged engineering detail and an internal channel full of polished nothing.

Run one channel per incident, named after the incident rather than the service. Everything relevant goes in it, including the boring parts: when the deploy went out, which region recovered first, who tried what. That log becomes the timeline in the write-up, and writing it afterwards from memory never works.

PagerDuty's guide puts role definition ahead of tooling, and that ordering is right. Two roles are enough for most teams: someone fixing the problem and someone talking about it. The incident commander can hold both on a small incident, but not on a severity 1.

Alert routing decides who ends up in that channel at all. There are 16 alert channel types, so a database failure can page the team that owns the database instead of a shared firehose everyone has muted.

The resolved update, and what comes after

The last piece of incident communication is the one people skim. A resolution note needs a start time, an end time and a duration, all with a timezone. Vague endings invite customers to keep watching. The duration is also the number that goes into your mean time to recovery, which is worth tracking honestly rather than flattering, as discussed in MTTR and MTBF.

Publish the write-up when you promised it. Five business days is a normal commitment and an easy one to keep if the timeline was captured while the incident was live. History retention on paid plans runs one year on Individual and two years on Enterprise as of September 2026. The check-level evidence is therefore still there when you write it up.

One limitation worth naming. A monitoring service can detect the failure, page the right channel and publish the incident, but the on-call rota and escalation policy live in a separate paging tool. Decide who owns the comms role before an incident, not during one.

Common mistakes

These are the incident communication failures we see most often.

Posting only after the cause is known. Diagnosis takes as long as it takes. Acknowledgement takes two minutes, and it is what customers are actually waiting for.

Letting engineers write customer updates while debugging. Context switching costs more than the update saves. Give the comms role to someone who is not holding a terminal.

Status page components that mirror your architecture. Name components after what a customer does, not after the service that broke. Nobody has an opinion about your queue worker.

One failed check opening a public incident. Confirm from a second region first, the pattern described in cross-region quorum confirmation. A public incident you retract in four minutes costs real credibility.

Good incident communication is mostly preparation. Write the templates on a calm afternoon, pick a cadence you can keep, name components in the customer's vocabulary, and tie the trigger to a confirmed monitor state. Set the page up before you need it. A basic status page on a subdomain is included on the free plan, which covers 10 monitors at a 1-minute check interval as of September 2026.