A Service Status Page: What Should Customers Hear During an Outage?

A useful service status page tells customers what is affected, what is known and when they should expect another update. It should not publish a guessed cause or announce full recovery merely because someone deployed a change. Agree the communication process as carefully as the page itself.

This is commissioning guidance for a customer-facing website or app. It is not a claim that your service needs a paid status platform, a promise of continuous support or a security-incident disclosure policy. Decide those responsibilities separately with the appropriate people.

Describe the customer effect before the technical cause

For a hypothetical ordering app, “Customers cannot submit new orders” is more useful than an unexplained database error name. Clarify whether existing orders, browsing and staff access are also affected. Do not label the entire service unavailable when the confirmed problem concerns one function.

The Atlassian Statuspage incident guide includes affected components when creating an incident. Use that as a product example for defining a manageable list of customer-facing service areas. Components should help readers understand scope, not expose an internal infrastructure diagram.

Record who confirms the impact and who publishes the message. A small team may give both responsibilities to one person, but there still needs to be a named fallback. Keep confidential customer details, internal logs and speculative blame out of public updates.

Separate what you know from what you have restored

Atlassian distinguishes Investigating, Identified, Monitoring and Resolved. Its definition of Investigating means symptoms are visible but the root cause is not yet known. Identified means the cause has been found and work on a fix is underway. Monitoring describes a believed fix while waiting for symptoms to subside.

Those stages make a useful briefing question: what evidence permits each transition in your own process? A change being deployed is not proof that every affected customer journey works again. Ask for a restoration check appropriate to the service before publishing an unqualified all-clear.

Use plain language alongside any status label. Explain what customers can try, what they should avoid and whether their earlier attempt needs follow-up. Do not advise repeated submissions if an earlier order or payment may already have succeeded. The correct recovery action needs technical confirmation, not a generic reassurance template.

Own the next update even when there is no new diagnosis

Agree who maintains the incident and what update cadence your actual support arrangement can sustain. A promised next update is a communication commitment, not a guaranteed repair time. If the cause remains unknown, say that instead of inventing progress to make the page look active.

Display the time and timezone clearly. Keep earlier updates understandable so customers can distinguish a past failure from the current position. If a previous statement was wrong, correct it explicitly rather than quietly making the history appear consistently accurate.

Separately decide how customers find the status information if the app itself is inaccessible. Rehearse that route in an isolated test; do not assume that a link inside the failed sign-in screen is sufficient.

Publishing and notifying are different decisions

The Atlassian creation flow explicitly asks whether subscriber notifications should be sent. Its documentation also says at least one affected component is needed for that option. These are product-specific details, not proof that every public edit alerts every customer.

Specify the intended audience and notification approval step for your own arrangement. Test messages must stay with controlled recipients. Do not import customer contacts into a subscriber list or enable external channels merely because an integration exists.

For acceptance, rehearse a partial failure, an unknown cause, a fix under observation and a return to confirmed working service. Check the public scope, timestamps, fallback access and intended test notification separately. Bring that rehearsal to a website or app handover. The deliverable is an honest communication path through a disruption, not a decorative green badge.