Incident Status Page Update Template

Decide the rules while nothing is broken. Google's SRE Workbook tells teams to prepare two or three ready-to-use templates¹: "No one wants to write these announcements under extreme stress with no guidelines." Then set, for each severity, how soon the first update goes out and how often the rest follow.

Public playbooks give you a range. PagerDuty, which sells incident response software, publishes its own major-incident process. It calls for a first notice within 5 minutes of starting the incident call², then updates at least every 20 minutes for the first two hours. Atlassian, which sells the Statuspage product, advises never going more than one hour without an update³ while customers are affected.

Then name who writes the updates. Google's SRE book walks through a scenario where the on-call engineer fixing an outage is far too busy to communicate clearly⁴, and customers are left frustrated. Give the job to one person with no technical task, named the moment you declare the incident.

Post as soon as you confirm customers are affected. Google's SRE Workbook warns that unless you acknowledge an incident, people will automatically assume nothing is being done¹ to resolve it. You won't know the cause yet, so use a shape that doesn't need one:

• The component, using the name on your status page
• What customers can't do, in their words: "card payments are being declined"
• Who is affected: a named group, "some customers" or "all customers"
• What isn't affected, if you're sure, such as stored card data
• The time of the next update

Leave out anything you might have to take back: an unconfirmed cause, a supplier you haven't told, a percentage of affected customers worked out on the fly. Leave out internal names too. PagerDuty's training for its customer liaisons notes that customers don't care if application-server-123 is having issues⁵; they care that their notifications aren't arriving.

End every update with a clock time: "Next update by 16:03 UTC." Atlassian's guidance is to always indicate when to expect the next update³. An update that ends "shortly" has promised nothing, so it can never be late, and nobody notices when the next one takes an hour.

Keep the promise even when nothing has changed: "Still moving traffic to backup systems, impact unchanged, next update by 16:33 UTC" is a complete update. Atlassian notes that people left in the dark start to expect the worst³. For incidents past two hours, PagerDuty's guidelines allow a slower cadence² to avoid empty updates, as long as each still says when the next will come.

Promise updates, never fixes. PagerDuty tells its liaisons not to estimate resolution times⁵: "Something else could happen, and customers get angry when you set an expectation you can't keep."

Label each update with the incident's state. Atlassian's Statuspage gives every incident one of four states⁶: Investigating (cause unknown), Identified (cause found), Monitoring (fix in, symptoms clearing) and Resolved (back to normal).

The status page talks to everyone, and two groups need more. Within the first hour, send support and account teams an internal brief. It covers what customers will have seen, sentences they can paste, what they must not say, and who decides on credits or refunds. Without one, they improvise answers the company then has to honor.

Some customers are owed direct notice. PagerDuty's guidelines say customers with special support contracts should also receive communication of impact delivered individually². Read your enterprise and reseller agreements now for clauses that require notice to a named contact within a set window. Nobody reads contracts mid-incident, and a public post won't reach a named contact.

Post the Resolved update once recovery is confirmed. PagerDuty's guidelines say it should confirm full recovery and give a clear indication of any data loss or lingering corruption², or say plainly that there is none. Then tell customers what to do: whether retries are safe, whether anything was charged twice, whether delayed data will arrive on its own.

Follow with a resolution note within a few working days, once the facts are settled. Give the impact window as clock times, such as 14:12 to 15:44 UTC, so customers can check it against their own logs. Add a few sentences on what happened and two or three specific changes. The full analysis belongs in a postmortem written from your incident data.

Consider one more line: your own cadence record. "We promised updates every 30 minutes, and the longest gap was 71 minutes" tells customers you measured what they lived through. They already know how long the silence was, because they were refreshing the page.

The template on this page holds the cadence policy, the component map and a Notification Log of promised and actual update times. Open it with Edit with AI, and River measures the gaps in your last few incidents from your status page history.