What is a Status Page? Definition and Uses

What is a status page?

A status page is a public web page that shows whether a service is working right now, how reliable it has been recently, and what the team is doing about any problem in progress. It is the page a customer opens when something feels broken and they want to know whether the fault is theirs or yours.

It is separate from the service it reports on. That separation is the whole point: if your application is down, a page hosted inside that application is down too. Status pages are therefore hosted independently, usually on a different domain or subdomain, so they stay reachable during exactly the outage they exist to explain.

What a status page contains

• Components: the parts of your service a customer would recognise, such as the API, the dashboard or logins. Each carries its own status.
• Overall status: a single roll-up at the top, so a visitor gets an answer without reading anything.
• Uptime history: commonly a bar per component covering the last 30 or 90 days, an honest record rather than a claim.
• Incidents: a timeline of what happened, updated as the team learns more, from investigating through to resolved.
• Scheduled maintenance: planned work announced in advance so it is not mistaken for an outage. See scheduled maintenance.
• Subscriptions: a way for customers to be told by email when something changes, instead of refreshing the page.

An example incident

Say your checkout API starts returning errors. A good status page shows this sequence on the affected component:

• Investigating: "Some checkout requests are failing. We are looking into it."
• Identified: "A faulty release caused the errors. We are rolling it back."
• Resolved: "Checkout is working again. A summary will follow."

Each update has a timestamp, the uptime bar keeps a visible gap, and subscribers get each step by email. Customers see that you noticed, know what is affected and know when it ended, without opening a support ticket. How to word those updates is covered in incident communication.

Manual pages versus monitor-driven pages

A status page can be updated by hand, which means it is only as current as the last person who remembered to edit it. During an incident, that person is usually busy fixing the incident.

A monitor-driven status page reads from checks that already run against your service, so component status and uptime history update themselves from real results. The page stays accurate without anyone touching it, and the uptime figures are measurements rather than assertions. Most teams combine both: monitors flip the status, people write the explanation.

Common mistakes

• Hosting it on the same infrastructure as the service. When the service goes down, so does the page that should explain it.
• Updating it late. A page that still says "all systems operational" while customers are failing teaches them to ignore it.
• Components nobody recognises. Internal names such as "queue-worker-3" tell customers nothing. Name components after what they do for the customer.
• Showing only green. Deleting incidents or hiding history removes the evidence that makes the page credible.
• No subscription option. Customers should not have to keep a tab open to find out when it is fixed.

Status pages and uptime monitoring

Because a useful status page is driven by monitoring data, the two are closely linked. API monitoring and synthetic monitoring supply the signal; the status page is where that signal becomes public. Uptime numbers also feed the commitments you make in an SLA.

Status pages on LoadFocus

LoadFocus publishes status pages driven by the checks you already run. You group monitors into sections and components, each showing live status and an uptime bar for 30 or 90 days. Incidents can be posted by hand with a minor, major or critical severity, or opened automatically when a monitor fails, and maintenance can be scheduled as one-off or repeating windows. Visitors can subscribe by email and follow only the components they care about. The free plan includes one page with 10 components and 250 subscribers (free API monitoring includes that page); a custom domain such as status.yourcompany.com is on paid plans. For tools you can host yourself, see our comparison of self-hosted status pages.

FAQ: status pages

Why should a status page be hosted separately?

Because it has to work when your service does not. A status page on the same servers, database or domain as your application goes down in the same outage, at the moment customers need it most.

Should a status page be public or private?

Customer-facing pages are normally public so anyone can check without logging in. A private page suits internal services or a single large customer, where only people you choose should see the status.

Can a status page update itself?

Yes, if it reads from monitoring checks. Component status and uptime history then follow real results. Incident explanations are still best written by a person.

What is the difference between a status page and uptime monitoring?

Monitoring runs the checks and alerts your team. A status page presents the outcome to your customers. Monitoring is the source of the data, the status page is the public view of it.

Do I need a custom domain for my status page?

It is not required, but status.yourcompany.com looks more trustworthy and is easier to remember. Keep it on infrastructure that is independent of your main service.