Blog / Status pages & incidents
Outage Notification Templates for Every Stage of an Incident
A good outage notice says what is affected, what users should expect, and when you will update next. Post a short "investigating" message within minutes, update at every stage change or at a promised interval, and close with a resolved notice and, for serious incidents, a follow-up that explains the cause and the fix.
An outage notification should answer three questions: what is broken, who is affected, and when you will say more. Use a short message at each stage of the incident (investigating, identified, monitoring, resolved), keep the status page as the single source of truth, and point email and social posts to it. The templates below are written to be copied, filled in and posted in under a minute.
Replace everything in [brackets]. Keep times in one time zone and name it, or use UTC.
Tone guidance before you copy anything
The words matter less than four habits:
- Lead with impact, not cause. Users want to know whether they can log in or pay, not which database replica failed.
- Be specific about scope. "Some users in Europe cannot upload files" is better than "We are experiencing issues."
- Promise the next update and keep the promise. Silence is what makes people angry, not the outage itself.
- Do not guess. Say "we are investigating" until you know. Never post an estimated fix time you cannot defend.
Avoid filler such as "We apologize for any inconvenience this may cause." If you apologize, apologize once, plainly, at the end of the incident. Avoid blaming users, other teams or vendors in public messages. And keep the language plain: "the site is down" beats "degraded availability of the web tier."
Stage 1: Investigating
Post this as soon as you have confirmed that real users are affected. The cause can be unknown.
Status page
Investigating - [Component, e.g. Dashboard login]
We are investigating reports that [users cannot log in to the dashboard].
[The public website and API are working normally.]
Next update by [14:30 UTC] or sooner if we learn more.
Email (only for customers you know are affected, or for long outages)
Subject: [Service] issue: [login unavailable] - investigating
Hi,
Since [13:52 UTC], [some customers have been unable to log in to the dashboard].
We are investigating and will post updates at [status page URL].
[Your data is safe, and scheduled jobs continue to run.]
We will email again when this is resolved.
[Name], [Company]
Only include the reassurance line if you have verified it. Do not write "no data was lost" during an incident unless you are certain.
Social
We're looking into a problem with [dashboard login] since [13:52 UTC]. Updates: [status page URL]
Stage 2: Identified
Post this when you know the cause well enough to work on a fix.
Status page
Identified - [Dashboard login]
We have identified the cause: [a configuration change to our login service].
We are [rolling it back] now. Users may still see [an error page] until this completes.
Next update by [15:00 UTC].
Describe the cause at the level a user can understand. "A bad deploy" or "an expired certificate" is fine. Internal hostnames, ticket numbers and the name of the engineer are not.
Social
Update: we've found the cause of the [login] problem and are deploying a fix. Details: [status page URL]
Stage 3: Monitoring
Post this when the fix is in place but you want to watch for a while before declaring the incident over.
Status page
Monitoring - [Dashboard login]
A fix has been deployed and [logins are succeeding again].
We are monitoring to confirm everything is stable.
If you still see problems, [sign out and back in / clear your browser cache / contact support at ...].
The monitoring stage is useful because a premature "resolved" followed by a second outage hurts trust more than a slightly longer incident. Keep it short: 15 to 60 minutes is common, depending on how quickly you can confirm recovery.
Stage 4: Resolved
Status page
Resolved - [Dashboard login]
This incident has been resolved. Between [13:52] and [14:41 UTC], [users could not log in to the dashboard].
The cause was [a configuration change to our login service], which we rolled back.
[We will publish a summary of what happened and what we are changing by Friday.]
We're sorry for the disruption.
Subject: Resolved: [login unavailable] on [date]
Hi,
The issue that prevented [dashboard logins] between [13:52] and [14:41 UTC] on [date] is resolved.
What happened: [a configuration change to our login service caused login requests to fail].
What we did: [rolled back the change and confirmed logins work].
What is next: [we are adding a check that blocks this kind of change before it reaches production].
[If you were billed / if a job did not run / if you need anything from us], reply to this email.
Sorry for the disruption,
[Name], [Company]
Social
Resolved: [dashboard login] is working normally again. Thanks for your patience. Summary: [status page URL]
Always state the start and end time in the resolved message. That is the information customers need for their own records and any SLA conversation. If you are unsure how downtime minutes translate into an uptime figure, see uptime percentage explained.
Scheduled maintenance announcement
Announce planned work in advance. A few days' notice is a sensible default for anything users will notice, with a reminder shortly before it starts.
Status page and email
Scheduled maintenance - [Database upgrade]
When: [Saturday 21 November, 02:00 - 03:00 UTC]
Impact: [The dashboard will be read-only for up to 20 minutes. The API will return 503 errors during that window.]
Not affected: [Public websites, status pages and email delivery.]
What you need to do: [Nothing.] / [Pause any imports scheduled during this window.]
We will post here when the work starts and when it is complete.
Start and finish notices
Maintenance in progress - [Database upgrade]. Expected to finish by [03:00 UTC].
Maintenance complete - [Database upgrade] finished at [02:34 UTC]. All services are operating normally.
If the work overruns, say so before the announced end time, not after. If maintenance returns HTTP 503 with a Retry-After header, clients and crawlers can handle it gracefully; the 503 Service Unavailable guide explains how.
Post-incident follow-up
For incidents that were long, affected many users or involved data, publish a short follow-up within a few days. It is a public summary of your internal review, not the review itself. The full internal version is covered in the blameless post-mortem template.
[Incident summary]: [Dashboard login outage] on [date]
Summary
On [date], between [13:52] and [14:41 UTC] ([49 minutes]), [customers could not log in to the dashboard].
[Websites, the API and alerts were not affected.]
Impact
[Approximately N% of login attempts failed during this window.] [No data was lost.]
What happened
[13:45] [A configuration change to the login service was deployed.]
[13:52] [Login errors began. Our monitoring alerted the on-call engineer.]
[14:20] [The change was identified as the cause.]
[14:35] [The change was rolled back.]
[14:41] [Logins recovered fully.]
Why it happened
[The change was valid in our test environment but referenced a setting that does not exist in production.
Our deploy checks did not compare the two.]
What we are changing
- [Deploy checks will validate configuration against production settings.] ([done])
- [Login errors above 5% will alert immediately rather than after 5 minutes.] ([by date])
We're sorry for the disruption and for the time it cost you.
Only include numbers you have actually measured. "Approximately" is fine; invented precision is not.
Choosing the channel
| Channel | Use it for | Avoid |
|---|---|---|
| Status page | Every customer-visible incident and all maintenance | Internal detail, blame |
| Long or serious incidents, affected customers, planned maintenance | Emailing everyone about a five-minute blip | |
| Social | Widespread incidents people are already noticing | Full updates; link to the status page instead |
| In-app banner | Degraded features users are about to touch | Leaving it up after resolution |
If you do not have a status page yet, the guide on how to create a status page covers what to include and where to host it so it stays up when your site does not.
Keep templates ready before you need them
Writing the first message during an outage is slow and error-prone. Save these templates where the on-call person can find them, pre-fill your component names and status page URL, and decide in advance who is allowed to post. The fastest first message also depends on how quickly you learn about the problem; PingRobot can send alerts by email or signed webhook when a monitor fails, so the clock on your first update starts with the monitor rather than with the first support ticket.
Start monitoring free — 10 monitors, no credit card.
Frequently asked questions
How quickly should I post the first outage notice?
As soon as you have confirmed that users are affected, even if you do not know the cause yet. A short "we are investigating" message beats a detailed one that arrives an hour later.
How often should I update during an outage?
State the time of the next update in every message and keep that promise. Every 30 minutes is a reasonable default for a major outage; post sooner when something changes.
Should I name the vendor that caused the outage?
Usually describe the cause in your own terms, for example "our payment provider", and take ownership of the impact on your users. Naming a vendor can be appropriate in a post-incident review once the facts are confirmed.
Do I need to post on social media for every incident?
No. Post on social channels for incidents that affect many users or that people are already talking about, and link to the status page so details live in one place.