What to write on a status page during an incident
How to write clear status page updates during an incident, with templates for each state, a default cadence and component statuses.
Published 14 November 2026.
The status page is the first place customers, support, and your team look during an incident. Clear updates stop the flood of "is it down?" questions and let responders work. This guide covers who posts, when, update cadence, incident states, component statuses, copy-paste templates, what not to say, scheduled maintenance, and the post-incident summary. For the wider incident process, see incident response basics.
Who posts, and when
- One person owns the status page for the incident: the communications lead, which PagerDuty calls the customer liaison. The incident commander approves each public message before it goes out (PagerDuty roles). See incident roles.
- Post early. Atlassian's incident communication tips say to acknowledge the problem quickly, even before the cause is known. PagerDuty's rule for the incident commander is "If in doubt, post it out" (during an incident).
- Have the first message ready in advance. PagerDuty's customer liaison training says to prepare a default initial message for when the scope is still unknown.
A sensible trigger (a recommendation): post as soon as the incident is declared and customers are, or will be, affected. Do not wait for the cause.
How often to update
Atlassian suggests updating every 30 minutes until resolution, adjusted for the situation. A recommended default cadence:
| Phase | Update interval |
|---|---|
| First post | As soon as customer impact is confirmed |
| Investigating, Identified | Every 30 minutes, even if nothing has changed |
| Monitoring | Every 30-60 minutes, or when the state changes |
| Resolved | Once, when users are no longer affected |
End every update with the next update time and keep that promise. "No new information, next update at 15:30 UTC" is valid. Use one time zone and name it.
The incident states
Atlassian Statuspage supports four incident states (create an incident docs):
| State | Meaning |
|---|---|
| Investigating | You see the symptoms but do not yet know the cause. |
| Identified | You have found the cause and are working on a fix. |
| Monitoring | A fix is in place and you are watching to confirm the symptoms are gone. |
| Resolved | The cause is fixed and the service is back to normal. |
You do not have to use every state. If a fix is already rolling out when you first post, starting at Identified is fine.
Component statuses
Components are the parts of your service customers recognise, such as "API", "Dashboard" or "Email delivery". Atlassian Statuspage gives each component one of five statuses (what is Statuspage): Operational, Degraded Performance, Partial Outage, Major Outage and Under Maintenance. The page's overall banner is worked out from the component statuses, for example any component in Major Outage shows "Partial System Outage" on a page with several components (status calculations).
When to use each (a recommended reading of the names):
| Status | Use when |
|---|---|
| Operational | Working normally. |
| Degraded Performance | Working, but slow or with elevated errors. |
| Partial Outage | Down for some users, regions or features. |
| Major Outage | Down for most or all users. |
| Under Maintenance | Planned work is in progress. |
Name components by what customers use, not by internal service names.
Templates for each state
Fill in the angle brackets. Each update says what users notice, what is being done and when the next update is.
INVESTIGATING
Title: <Feature> <errors / slowness / unavailable> for some users
We are investigating reports of <symptom users see, e.g. failed logins> on <feature or region>.
<Workaround, if any: e.g. "Logging in through the mobile app still works.">
Next update by <HH:MM UTC>.IDENTIFIED
We have identified the cause of <symptom> and are working on a fix.
<What users can expect: e.g. "Some payments may be delayed but will not be lost.">
Next update by <HH:MM UTC>.MONITORING
A fix has been applied and <feature> is recovering. We are monitoring to confirm.
<Anything users need to do: e.g. "If you still see errors, refresh the page.">
Next update by <HH:MM UTC>.RESOLVED
This incident is resolved. From <HH:MM> to <HH:MM UTC>, <what users experienced>.
<Any lasting effect: e.g. "Emails queued during this time have now been delivered.">
We are reviewing the cause and will share a summary <when>.What not to say
- No guessing. PagerDuty's customer liaison training says never lie or guess. Write "We are investigating", not a cause you have not confirmed.
- No resolution estimates. The same training says not to estimate resolution times. Promise the next update instead.
- No internal names. Customers care about what they can and cannot do, not hostnames, clusters or service names.
- No blame. Atlassian's tips say to own the problem even when another provider caused it, because to the customer it is a problem with your service. Do not name the vendor or the engineer.
- No minimising or inflating. PagerDuty's postmortem writing guide suggests "incident" or "service degradation" rather than "outage" unless the service was fully down. Say plainly which users are affected.
- No silence. A missed next-update time reads as the team having gone quiet.
Scheduled maintenance
Atlassian Statuspage moves maintenance through four states (schedule maintenance): Scheduled, In progress, Verifying (the work is done and you are checking it) and Completed. It can switch to In progress and Completed automatically at the scheduled times and set affected components to Under Maintenance. Email and SMS subscribers get a reminder 60 minutes before the start.
Post the notice far enough ahead for customers to plan around it. Post earlier for anything with downtime. Silence the matching alerts for the same window. See silences and maintenance windows.
SCHEDULED MAINTENANCE
Title: Scheduled maintenance: <feature> on <date>
On <date> from <HH:MM> to <HH:MM UTC>, we will <plain description, e.g. upgrade the database behind the dashboard>.
During this window, <exact effect: e.g. the dashboard will be read-only for up to 15 minutes>. <Feature> is not affected.
No action is needed from you. Updates will be posted here.The summary after the incident
Publish a public summary for significant incidents after the internal review. Atlassian Statuspage allows postmortems only on resolved incidents and recommends them for major outages. Apologise, explain the cause, and state the fixes (create a postmortem). PagerDuty structures external messages in three parts: a two or three sentence summary, what happened, and what is being done, with proprietary details removed.
SUMMARY: <Title of incident>
On <date>, from <HH:MM> to <HH:MM UTC>, <what customers experienced, and how many or which ones>.
We are sorry for the disruption this caused.
What happened
<Plain-language cause, no internal names, no blame. e.g. "A configuration change reduced the capacity of our login service.">
What we are doing about it
- <Change already made>
- <Change planned, with timing if committed>The internal version is the blameless postmortem.
Tools
Status page platforms host the page, manage subscribers, and store templates for each incident state. Browse the status pages directory or view tools filtered by status page.