Status Page

When a service fails, customers need to know whether the issue is known and what to expect, and a status page offers one place to check, though it should not replace direct support for individual cases. Atlassian documents incident and maintenance communication through Statuspage, and Google Cloud describes personalised service health as distinct from public status.

These examples show why scope and audience matter. A fictional software company sees login failures and posts an incident showing affected regions and the time investigation began, so customers can avoid repeating basic diagnosis.

A page can show components such as login, payments and API separately, and a green overall label should not hide a partial outage, so each component needs a definition. A fictional platform whose API works but whose dashboard is down marks the dashboard degraded rather than calling the whole service unavailable, and the detail helps customers plan.

Post updates with timestamps and time zones, saying what is known, what remains unknown and when the next update is expected, and avoid guesses about resolution time. A fictional provider says, "We are investigating elevated payment errors; next update in 30 minutes," without promising a 30-minute fix, which prevents false expectations.

State customer impact in plain language, because internal error codes alone are not enough, and include workarounds only if tested and safe, as a fictional app did when it verified its web checkout path before suggesting it while mobile checkout failed, since a speculative workaround could create new failed orders. Incident stages may include investigating, identified, monitoring and resolved, and these labels should reflect operational evidence, so "resolved" should follow verification, not merely deployment.

A fictional team that releases a patch but still sees errors keeps the status at monitoring until recovery is confirmed and does not close the incident for appearances. Planned maintenance belongs on the page too, with advance notice where possible, time zone and expected impact, and the record should be updated if the window extends or ends early, as when a fictional provider schedules a database change, shows the affected feature and likely interruption, and posts a completion update after testing.

Subscriptions can send email, text or other alerts to interested customers, but they require consent and reliable delivery, and the page itself should remain accessible if notifications fail. A fictional customer who opts into API alerts only avoids irrelevant messages, because the provider does not presume all users want every notification.

Public status may lag or omit issues that affect one tenant, region or account, so personalised health and support channels can fill that gap, and a green page is not proof the customer is mistaken, as a fictional client with a failed integration found when support investigated account-specific logs instead of closing the ticket by citing the page. A trustworthy history shows past incidents and durations with useful explanations, and editing history to conceal an outage damages credibility, so factual errors should be corrected transparently, as a fictional provider did when it found a regional impact was global and noted the correction.

The status page must be reachable during the product outage, so host it separately or have a fallback and test the communication path as part of incident preparation, because a fictional company that hosted its page on the same failing server as its app lost both during an outage and moved the page to an independent provider. After an incident, link to a postmortem when appropriate and track corrective work, keeping sensitive security details out of public updates; the page records communication, not a fix for the root cause, and it works as a live promise of honest service information updated at a useful cadence.