Status Page Message Templates: Incident and Maintenance Examples

When something breaks, the hardest part of writing an update is not the facts. It is finding the words while you are also trying to fix the problem. The solution is to write the templates in advance, so during an incident you fill in blanks instead of composing prose under stress. This guide gives you templates for each stage of an incident and for planned maintenance, followed by complete worked examples and the tone rules that make them work.

For the broader question of what a status page should contain and how to organize components, read the website status page guide. This page focuses on the words.

Tone rules

Customers in the middle of an outage are not looking for charm. They want to know four things: is it you or me, what is affected, are you working on it, and when will I hear more. Write to answer those.

1. Say what users experience, not what you think is broken. "Some customers cannot complete checkout" beats "elevated error rates on the payment microservice."
2. Be specific about scope and time. Include which component, which users, and since when, in a stated time zone (use UTC or your customers' main zone consistently).
3. Never guess at causes or fix times in public. "We expect a fix within 10 minutes" becomes a broken promise. Promise the next update instead.
4. Promise the next update and keep it. "Next update by 15:30 UTC" is a commitment you can keep even when you have no news.
5. Avoid blame and jargon. Do not name a vendor as the culprit unless you must. "A service we depend on" is usually enough, and it keeps the focus on what you are doing about it.
6. Be calm and plain. Skip exclamation marks, humor and "we deeply value your business" boilerplate. A sincere single "we are sorry for the disruption" in the resolved message is enough.
7. One voice. Pick one person to write public updates during an incident, so the tone and facts stay consistent.

The four-stage template set

Most status pages use the same four statuses: Investigating, Identified, Monitoring and Resolved. Here are the fill-in-the-blank versions.

1. Investigating

Use as soon as you have confirmed users are affected, even before you know the cause. Speed matters more than detail.

Title: [Component] [problem in plain words]

Investigating - [HH:MM TZ]
We are investigating reports that [what users see, e.g. the website is
loading slowly / some orders fail at checkout]. [Who is affected, if known.]
We will post another update by [HH:MM TZ].

2. Identified

Use once you know what is wrong and are working on a fix. You do not need to give deep technical detail.

Identified - [HH:MM TZ]
We have identified the cause of [the problem] and are working on a fix.
[One plain sentence on the cause, only if you are sure.]
[Workaround if one exists.]
Next update by [HH:MM TZ].

3. Monitoring

Use after a fix is applied, while you confirm that it holds.

Monitoring - [HH:MM TZ]
A fix has been applied and [the service] is recovering. We are monitoring
to make sure it stays stable. [Any lingering effects, e.g. some pages may
still load slowly for a few minutes while caches refill.]
Next update by [HH:MM TZ], or sooner if anything changes.

4. Resolved

Use only when you have confirmed normal operation.

Resolved - [HH:MM TZ]
This incident is resolved. [The component] has been working normally since
[HH:MM TZ]. The issue affected [who/what] from [start] to [end]
([duration]). [One sentence on the cause, if known.] We are sorry for the
disruption. [We will publish a summary of what happened and what we are
changing by <date>. / No action is needed on your side.]

Worked example: web server outage

This is a complete incident timeline for a fictional shop called "Alder & Finch." Note how each message is short and the scope stays clear.

Title: Website unavailable

Investigating - 14:12 UTC
We are investigating reports that alderfinch.example is not loading for
many visitors. Orders already placed are not affected. We will post
another update by 14:40 UTC.

Identified - 14:31 UTC
We have identified the cause: the server ran out of disk space and the
website stopped responding. We are freeing space and restarting the
service. Next update by 14:50 UTC.

Monitoring - 14:46 UTC
The website is loading again. We are monitoring to make sure it stays
stable. Next update by 15:15 UTC.

Resolved - 15:12 UTC
This incident is resolved. The website was unavailable from 14:04 to
14:44 UTC (40 minutes). The cause was a full disk on our web server.
We are sorry for the disruption. We are adding disk space alerts and
will publish a short summary of the changes by Friday.

Each update states a next-update time, and the resolved message gives the real duration and the cause in plain words. Note that the start of impact (14:04) is earlier than the first post (14:12): report when impact began, not when you noticed.

Worked example: partial degradation

Not every incident is a full outage. Be equally clear about partial problems.

Title: Slow checkout for some customers

Investigating - 09:20 UTC
Some customers are seeing slow page loads or timeouts at checkout.
Browsing the shop is working normally. We are investigating. Next update
by 09:50 UTC.

Identified - 09:44 UTC
Our payment provider is responding slowly, which is delaying checkout.
You can retry in a few minutes; if you see an error, please check your
email before trying again, because your order may have been placed.
Next update by 10:15 UTC.

Resolved - 10:08 UTC
Checkout is working normally again. Some orders placed between 09:10
and 10:00 UTC may have shown an error even though they were received.
If you did not get a confirmation email, contact support and we will
check. We are sorry for the confusion.

This example gives users something to do (check email before retrying), which prevents duplicate orders. Whenever there is a user action that reduces harm, state it.

Planned maintenance templates

Maintenance messages should go out in advance, repeat shortly before, and close when done. They are calmer than incident messages, but the same rules apply: be specific.

Announcement (send several days ahead where practical)

Scheduled maintenance: [what]

Scheduled for [date], [HH:MM-HH:MM TZ] (about [duration]).
What will happen: [one sentence].
What you may notice: [e.g. the website will show a maintenance page /
checkout will be unavailable for up to 15 minutes / no interruption
expected].
What you need to do: [nothing / save your work beforehand].
Why: [one sentence, e.g. upgrading our database to improve reliability].

Reminder, start and completion

Send a short reminder about an hour before ("Maintenance begins at [HH:MM TZ] today"), an "In progress" note when it starts, and a "Completed - all systems operating normally" note when it ends.

Worked example

Scheduled maintenance: database upgrade

Scheduled for Sunday 12 October, 02:00-03:00 UTC (about 1 hour).
We will upgrade our database server. The website and account area will be
unavailable for up to 20 minutes during this window; orders cannot be
placed at that time. No action is needed on your side.
We chose this time because it has the lowest traffic of the week.

If it overruns, say so with a new estimate rather than going silent. Mark the window in your monitoring so planned downtime does not trigger false alerts or count against your uptime figures; see website maintenance mode done right.

Special cases

Third-party provider outage

Say what is affected and that your own site is working, and own the communication without blaming the vendor by name: "Some customers cannot receive email notifications because of an outage at a service we depend on. We will update here when delivery resumes."

Possible security issue

For anything involving data exposure, check with whoever is responsible for security and legal obligations before posting. Notification rules vary by country and industry. A holding statement is acceptable while you confirm facts:

We are investigating a possible security issue affecting [system]. As a
precaution, [action taken]. We will provide an update by [time]. If we
find that customer data is affected, we will contact affected customers
directly.

Update cadence

• Post the first message quickly, typically within 10 to 15 minutes of confirming impact. A short message beats a perfect one later.
• Update at the interval you promised. If you have no news, post "no change, still working on it" at the stated time.
• Every 30 minutes is common for a major incident; pick a rhythm you can keep.
• Close every incident. A page full of unresolved items looks abandoned.

Do not host your status page on the thing that breaks

If your status page lives on the same server as your site, an outage takes both down. Use a separately hosted page, such as the SiteDownCheck status page, and point to it from your site's header or support page. You can also embed a compact indicator with the status widget.

Next steps

• Create your page with the status page tool and save these templates.
• Start detecting outages automatically with the uptime monitor.
• Embed a live indicator with the status widget.
• Read the status page guide for structure and components.
• Use the postmortem template guide after serious incidents.

FAQ

How soon after an outage should I post?

As soon as you confirm users are affected, ideally within 10 to 15 minutes. A short "we are investigating" message is better than waiting until you know more.

Should I name the cause in public?

Only when you are sure. Plain, accurate causes such as a full disk or a provider outage build trust. Guesses that later prove wrong damage it.

Should I give an estimated time to fix?

Avoid it unless you are confident. Promise the time of your next update instead, which you can always keep.

How far ahead should I announce planned maintenance?

Enough for customers to plan around it. Several days is common for impactful work, with a reminder shortly before. Check any notice period in your SLA.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.