Every outage message gets written twice. Once in advance, by someone calm, with time to choose words. Once during the incident, by whoever happens to be awake, in a hurry, while also trying to fix the thing. The first version is always better, which is the entire argument for having templates at all.
Three Templates Cover Almost Everything
Long template libraries look thorough and fail in practice, because nobody reads a menu of twelve options at 3 a.m. Three named messages, in a known order, get used.
Each outage notification template below is deliberately short enough to fill in without thinking. Square brackets mark the only decisions you make live.
1. Acknowledge
Send within minutes of confirming the problem. It exists to stop people guessing.
[Service] — investigating
We're aware that [specific symptom, in customer language] since
[time, with time zone]. [What still works, if anything does.]
We're investigating now and will post an update by [clock time],
whether or not we have a fix.
Status: Investigating
2. Update
Send on the clock you promised, even when nothing has changed.
[Service] — update
[What we know now, one or two sentences.] [What we've ruled out.]
[If the cause is known: what we're doing about it.]
[If it isn't: we're still narrowing it down.]
Next update by [clock time].
Status: Identified / Monitoring
3. Resolved
Send once you believe it’s over, and say what happens next.
[Service] — resolved
[Symptom] was resolved at [time, with time zone]. The cause was
[plain-language cause]. Total impact: [duration] affecting
[who or what].
[Any action customers need to take, or explicitly: no action needed.]
[If you'll publish more detail: when.]
Status: Resolved
That’s the set. A fourth for planned work is worth adding if you ship maintenance windows regularly, and scheduled maintenance has its own rules that don’t belong in an outage template.
Never Put a Fix Time in the Template
A blank labelled “estimated resolution” is a trap, because the honest answer during most incidents is that you don’t know, and the number you invent under pressure becomes the thing you’re judged against. Miss it and you’ve turned one problem into two.
Replace it with a next-update time. That is a promise you control completely: it needs no diagnosis, no vendor, and no luck, and hitting it repeatedly is what makes people stop refreshing and go back to work. Choose 30 minutes for anything customer-facing and hold the line even when the update is “still working on it.”
Two more rules worth building into the blanks. Describe the symptom the way a customer experiences it, not the way your architecture does, because “checkout is failing” lands and “the payments pod is CrashLoopBackOff” does not. And name what still works. People plan differently when they know reads are fine and only writes are broken.
The Template Was Never the Hard Part
Copy the three above and you’ve solved perhaps a third of the problem. The rest is mechanical, and it’s where outage communication actually breaks down.
Two questions decide whether any of this happens. What makes someone start writing, and where does the message land? A template with no trigger is a document nobody opens. A trigger with no audience is a status page that three people have bookmarked.
The audience half is the easier one to fix and the more commonly skipped. A status page with email subscriptions turns a page people would have to think to visit into a message that arrives. In FlareWarden, visitors subscribe from the page itself, confirm through double opt-in, then receive updates during incidents and maintenance with one-click unsubscribe in every email. Every plan including the free one comes with a status page and subscribers, so an outage notification template has somewhere to go from day one.
The trigger half is where most teams stall, because it feels like a tooling question and is really a policy one. Decide two things in advance and write them next to the templates: which monitors are customer-facing enough to justify a public message, and who is allowed to send it. Both answers should be boring, and both should be written down somewhere that isn’t one person’s memory.
Don’t Wire Customer Email to a Single Failed Check
The trigger half deserves more suspicion than it usually gets, and this is the part we’d argue hardest about.
Automating “monitor goes down, customers get emailed” sounds like the obvious win and is the fastest way to email 400 people about an outage that never happened. We run probes on multiple continents, and single-region failures that resolve on their own are ordinary: a route flaps, one edge sees a timeout, everything else is fine. That’s why FlareWarden validates a failure from other regions before calling a monitor down, and why false-positive downtime alerts get their own engineering rather than a shrug.
So keep the automation asymmetric. Let detection be automatic and let the customer-facing message stay human, gated on a person deciding this is real. The cost of a 90-second delay before the acknowledge message is close to nothing. The cost of retracting an outage notice is a permanent dent in whether the next one gets believed.
An exception worth naming: internal channels can fire on the raw signal. Wake the on-call from the first failed check if you like, then let a human promote it to the public page.
The Resolved Message Is the One People Remember
Most teams communicate reasonably during an incident and then go quiet the moment it’s fixed, because the adrenaline is gone and there’s cleanup to do. That silence gets read as “still broken,” and support keeps answering tickets for a problem that ended an hour ago.
Send the resolved note, name the duration, and say plainly whether anyone needs to do anything. If you promise a fuller write-up, either publish it or don’t offer it. Both are fine; a promised post-mortem that never appears is worse than never mentioning one.
One habit makes the whole set better over time: after each incident, edit the outage notification template you actually used. The blanks you struggled to fill are telling you something, and five minutes of editing while the memory is fresh beats a rewrite scheduled for a quiet week that never arrives.
Keeping the incident visible afterwards is part of the same job. A status page that retains incident history gives the next skeptical prospect something better than a claim, and being honest about uptime in public survives scrutiny better than a page that has always been green.
Key Takeaways
- Three templates beat twelve — acknowledge, update, resolved, in a known order, get used under pressure in a way a large library never does.
- Promise a next update, never a fix time — the update time is entirely within your control, and inventing an ETA creates a second failure to explain.
- Write the symptom in customer language — and say what still works, because partial impact changes what people do next.
- Keep detection automatic and publication human — one region’s failed check is not proof of an outage, and a retracted notice costs more than a slightly later one.
- The resolved message does real work — silence after a fix reads as ongoing breakage and keeps support answering closed tickets.
Want your status page to send the update while you’re still fixing the problem? Start free with FlareWarden — status pages with email subscribers included, 15 monitors, no credit card required.