Status pages that update themselves from live health

What are status pages?

Status pages are web pages that show the current health of a service, broken down into components such as API, web app, checkout or login. A public status page tells customers whether a problem is on your side and what you are doing about it. An internal status page gives support, sales and engineering a shared view of degraded dependencies, ongoing incidents and planned maintenance. Both answer the same question as quickly as possible: is it working right now?

Most teams start with a manually maintained page. Someone has to notice the outage, log in to a separate tool, change a component to "degraded" and write an update. During a real incident that person is usually busy fixing the problem, so the page lags reality, sometimes by an hour or more. A status page that only updates when a human remembers to update it erodes trust exactly when trust matters most.

Why automated status pages matter

An outage creates two problems: the technical failure and the communication gap around it. When customers cannot tell whether an issue is local or global, they open tickets, post on social media and escalate to account managers. Every one of those contacts costs time that the team would rather spend on recovery.

Status pages driven by live health data close that gap. The moment a synthetic check fails from several locations or an SLO starts burning error budget fast, the affected component changes state. Incident commanders can then add human context, such as scope, workaround and next update time, instead of first having to establish the basic facts on the page. The result is faster, more consistent communication and a lower load on support during incidents, which also shortens the overall time to resolve.

Signals behind component status

A good status page is only as good as the signals that drive it. In Obseria you can combine several sources per component:

• Synthetic checks from 50+ locations, which show whether an endpoint is reachable and correct from the outside.
• SLO burn rate, which reflects how fast the error budget for availability or latency is being consumed.
• Golden signals such as error rate and latency of the underlying services, taken from traces and metrics.
• Open incidents with their severity, so a declared SEV1 always shows up on the affected components.
• Real user monitoring data, for example a sudden drop in successful page loads in a region.

Each rule maps to a state: operational, degraded performance, partial outage or major outage. You decide the thresholds and how long a condition must hold before the page changes, which prevents flapping on short spikes.

How Obseria builds status pages

Obseria status pages sit on top of the service catalog and Obseria TopoGraph. You choose services, checks and SLOs and group them into components that make sense to your audience; a customer does not need to know that "checkout" depends on six microservices and a payment gateway. Because the topology is known, a failing dependency can mark the right components as degraded automatically.

Incidents created in Obseria incident management can be linked to components. Updates written in the incident timeline are published to the status page with one click, so the incident channel and the public page never tell different stories. Scheduled maintenance windows appear on the page in advance and suppress alerts for the affected services while the window is open. Uptime history is calculated from the same data that feeds your SLO dashboards, so the numbers on the page match the numbers in your reports.

Public pages can run on your own domain with your branding. Internal pages are protected by SSO and RBAC and can show much more detail, including dependency health, regions and links to dashboards for support staff.

Status page best practices

1. Model components from the user's perspective. List capabilities customers recognise, not internal service names.
2. Automate detection, keep humans for context. Let signals set the state; let people write the explanation, impact and next update time.
3. Use hold times. Require a condition to persist for a few minutes before changing the public state to avoid noise.
4. Post updates on a fixed rhythm. During an incident, commit to an update interval and keep it, even if there is no news.
5. Separate audiences. Keep the public page simple and put detailed dependency status on the internal page.
6. Review after incidents. Check in the post-mortem whether the page changed at the right time and adjust rules accordingly.