During an outage, customers judge you on two things: how fast the problem is fixed, and what they hear while it is being fixed. You can’t always control the first. The second is entirely up to you, and it’s the part most teams improvise.
Improvising goes wrong in predictable ways. Nobody posts anything for an hour because everyone is fixing the problem. Three people post three different versions. The update says “a degradation in the eu-west cluster” and customers have no idea whether it affects them. This guide gives you a one-page plan to decide those things in advance, and templates to copy.
The one-page plan
Write this down once, keep it where the on-call person can find it, and review it twice a year.
Roles
- Incident lead: owns the incident, decides severity, coordinates the fix.
- Communicator: writes and posts every customer-facing update. Not the same person as the one fixing the problem; fixing and writing at the same time means one of them suffers.
- Support: answers incoming questions with a link to the status page, and passes on what customers report.
In a small team, the same people wear several hats. The point is to decide who does what before the outage, not during it. Pairing this with an on-call schedule means the first two roles always have a name.
Severity levels
Three levels are enough for most teams:
- Major: the product, checkout or login is down or unusable for most customers. Update every 30 minutes.
- Minor: one feature is broken or slow, or a part of your customers is affected. Update every hour.
- Maintenance: planned work. Announce in advance, update when it starts and ends.
Channels
- Status page: always, for every customer-facing incident. It’s the source of truth the other channels link to.
- Subscriber notifications: email and chat notifications from the status page, so customers don’t have to keep refreshing.
- In-app banner: for major incidents, if your product has one.
- Direct email: for major incidents that affected key accounts, and for the follow-up summary.
- Social media: for major incidents, with a link to the status page, not a separate version of the story.
Promises
- First update within 15 minutes of knowing about a customer-facing problem.
- Every update says when the next one will come.
- Every incident ends with a resolved update.
- Major incidents get a short written summary within five working days.
What a good update contains
Every update, at every stage, answers four questions in this order:
- What is affected, in the words customers use: “checkout”, “the mobile app”, “sign-in”, not the internal service name.
- What they notice: errors, slowness, missing emails.
- What they can do, if anything: a workaround, or “no action is needed”.
- When they will hear more.
Things to leave out: guesses about the cause, internal names and jargon, blame on a named supplier or colleague, and promises about when it will be fixed unless you are sure. “We expect to have this resolved within 30 minutes” is a promise customers will hold you to.
Templates for each stage
Replace the parts in brackets. Keep the tone plain and calm.
Investigating
We’re investigating reports of [errors / slow loading] when [customers try to check out]. [Other parts of the site are working normally.] We’ll post an update within [30 minutes].
Identified
We’ve identified the cause: [a problem with our payment provider / a faulty update we released at 14:05]. [Card payments fail; invoices and Swish are not affected.] We’re [rolling back the update / working with the provider] and will update again within [30 minutes].
Monitoring
A fix is in place and [checkout] is working again. We’re monitoring to make sure it stays stable. [Orders placed between 14:05 and 14:40 may show as pending; they will be processed automatically.] Next update within [one hour], or sooner if anything changes.
Resolved
This incident is resolved. Between [14:05 and 14:40 CET], [card payments at checkout failed for most customers]. [The cause was a faulty update, which we’ve rolled back.] [We’re adding a check so this kind of error stops a release before it reaches customers.] We’re sorry for the disruption.
No news yet
We’re still working on [the checkout errors]. There’s no change since the last update. Next update within [30 minutes].
That last one matters more than it looks. A status page that hasn’t changed in an hour makes customers think nobody is working on it.
Email to affected customers
For major incidents that hit key accounts, a short email after the incident is worth more than any status page. Send it from a person, not a no-reply address.
Subject: About today’s checkout outage
Hi [name], between 14:05 and 14:40 today, card payments at checkout failed for most of our customers, including you. The cause was a faulty update on our side, which we rolled back. [Orders you placed in that window have now been processed.] We’re [adding an automatic check that stops this kind of release]. If you saw anything that doesn’t match this, reply to this email and I’ll look into it personally. [Name, role]
Social media
Keep it short and point to the status page for details:
We’re seeing errors at checkout and are working on it. Updates here: [status page link]
Checkout is working again. Thanks for your patience, and sorry for the trouble. Summary: [status page link]
After the incident
For major incidents, publish a short summary on the status page or by email within a few days: what happened, how long, who was affected, what caused it and what you’re changing. Our postmortem template covers the internal review that comes first, and how to turn it into a customer-facing version.
Then look at the communication itself. How long did the first update take? Were the promised update times kept? Did support get questions the updates should have answered? Fix the plan, not just the system.
Make it easy to follow the plan
A plan works only if it is faster to follow than to ignore. A few things make the difference:
- Know before customers do. Uptimecheck checks your sites and APIs every minute from Stockholm, Sweden, confirms each failure with a second check and alerts the on-call person, so the 15-minute clock starts when the problem starts, not when the first support ticket arrives.
- Templates ready in the tool. Uptimecheck status pages offer a ready-made first draft for each stage (investigating, identified, monitoring, resolved) in the page’s language, and your own saved templates, where
{components}fills in the affected parts. - Notify the right people. Subscribers follow the whole page or only the components they use, by email, Slack, Microsoft Teams, Discord or webhook, and only those who follow the affected components are notified.
- Announce maintenance in advance. Scheduled maintenance shows on the page and is emailed to subscribers before it starts.
Our guide to creating a status page customers trust covers what to put on the page itself.
Checklist
- Name the incident lead, communicator and support roles in advance.
- Agree on three severity levels and an update cadence for each.
- Use the status page as the source of truth; other channels link to it.
- Post the first update within 15 minutes, even if all you know is that you’re investigating.
- Answer what’s affected, what customers notice, what they can do and when they’ll hear more.
- Give the time of the next update, and keep it.
- Close every incident with a resolved update.
- Send a short summary after major incidents, and review the communication as well as the fix.