Status page best practices for calm incident communication

Components are the rows on the page, each with its own state. Name them after what customers use, not after your internal services. Nobody outside your team knows what "worker-pool-2" is, but everyone knows "Login" and "Checkout".

• Website. The marketing site and docs.
• Web application. Login and the main product interface.
• API. The public API and webhooks you send.
• Payments or checkout. Where money changes hands.
• Notifications. Email or messages your product sends.
• Integrations. Connections to tools customers rely on, grouped together.

Keep the list between four and ten components. Fewer than four hides useful detail, more than ten turns the page into a dashboard nobody reads. If you serve several regions and failures are often regional, group components by region.

A component that someone has to update by hand will be wrong at the worst moment, because the person who would update it is busy fixing the outage. Link each component to the monitors that represent it. When a confirmed failure starts, the component changes state, and the team adds the human explanation on top. On UptimePilot, status page components connect to monitors, and a monitor is marked down only after a second region confirms the failure, so the page does not flicker on a single network hiccup.

An incident update has one job, which is to tell a customer what they can expect. Use short sentences. Say what is affected, what is not, what you are doing and when the next update comes. Skip internal detail, blame and guesses about root cause.

• Say which feature is affected, in customer words.
• Say what still works, which often matters as much.
• Give the time of the next update, and keep the promise.
• Use one time zone throughout and say which one.
• Do not promise a fix time unless you are confident.

Silence is what makes people open tickets. During an active incident, post an update at least every 30 minutes, even if the update is that the investigation continues. For a long outage, every 60 minutes is acceptable once you say so in advance. The cadence matters more than the content of each update. People relax when they can see that someone is on it.

Prepared wording saves minutes when nobody has minutes. Keep these in your runbook and adjust the bracketed parts.

• Investigating. We are investigating reports that [feature] is not loading for some customers. [Other features] are working normally. Next update by [time, time zone].
• Identified. We have identified the cause of the [feature] issue and are working on a fix. Customers may see [symptom] until this is resolved. Next update by [time].
• Monitoring. A fix for the [feature] issue is in place and we are watching the results. [Feature] is working again for most customers. Next update by [time].
• Resolved. The [feature] issue is resolved. Between [start time] and [end time, time zone], customers could not [action]. We will publish a short summary of what happened.
• Degraded performance. [Feature] is responding more slowly than usual. All actions complete, but some take longer. We are working on it and will update by [time].

Four stages (investigating, identified, monitoring, resolved) are familiar to most readers. Using them consistently tells customers where you are without extra words.

Planned work deserves the same clarity as an incident, with more notice. Post it on the status page at least a few days ahead for anything customer visible, and a week ahead for longer windows.

• Say what is affected and what stays available.
• Give the start and end time with the time zone.
• Say whether customers need to do anything.
• Post a short note when work starts and when it ends.
• If the work runs over, update the notice before the window closes.

On UptimePilot, scheduled maintenance appears on the status page, and a matching maintenance window pauses alerts for the affected monitors while checks keep running.

Most customers will not refresh a status page. Let them subscribe to email updates, so incident and maintenance notices reach them directly. Encourage your largest customers and your support team to subscribe, and link the subscription option from your help center and account settings. Subscriber email updates are part of every UptimePilot status page. For internal alert channels, which are separate from customer updates, see the website downtime tracker page.

After a significant incident, customers want to know that it will not happen again for the same reason. Publish a short summary within a few days on the incident itself.

• What happened, in two or three sentences.
• When it started and ended, and who was affected.
• What caused it, at a level a customer understands.
• What you changed, and what you are still changing.

Keep it factual and brief. A long, defensive document reads worse than a short honest one. The detailed internal review can stay internal.

A public page works for most SaaS products and stores. It answers questions from prospects as well as customers, and it shows confidence. A password protected page fits internal tools, client portals and agencies that run separate pages per client, where the audience is known and the component list includes details you would not publish. UptimePilot supports both, with password protection on Business and Enterprise.

A status page that runs on the same servers, network or DNS setup as your product goes down with it, which is exactly when you need it. Host it separately and point a subdomain such as status.yourdomain.com to it with a CNAME record. That keeps your brand and the familiar address while the page itself lives on independent infrastructure. Use a short DNS time to live on that record, and do not let the status page depend on your own login system, CDN configuration or analytics scripts to load. UptimePilot hosts status pages separately from your systems and supports a custom domain from the Team plan.