How to Set Up a Public Status Page for Your Website or Service

What a status page does and why it pays off

A status page is a public page, usually at status.yourdomain.com, that shows whether each part of your product works right now and what the team is doing about problems.

During an incident, most support requests ask the same thing: "Is it broken for everyone, and when will it be fixed?" A status page answers that once, for everyone. The result:

• Fewer duplicate tickets and calls while engineers fix the problem.
• More trust: users see that you noticed the issue before they reported it.
• A record of past incidents that sales and support can point to.

What to show on the page

Keep it understandable for a non-technical customer. Show components the user recognizes, not your internal servers.

For each component, use a small set of states: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

Useful extras:

• Uptime history for the last 30–90 days per component.
• Response time chart for the API or website, if it is stable and meaningful.
• Scheduled maintenance announced in advance.
• Subscriptions: email, RSS, webhook or a Telegram channel, so users get updates without refreshing.

Do not publish everything you monitor. Internal metrics without context cause more questions than they answer.

Host it separately from your main infrastructure

The status page must stay up when your product is down. If it lives on the same server, in the same cloud account or behind the same load balancer, it fails together with everything else.

Checklist:

• Different hosting: a SaaS status service, a static site on another provider, or at least a different region and account.
• Independent DNS: if your main DNS provider has an outage, status. should still resolve. Consider a separate zone or provider for it.
• No dependency on your login, database or API.
• A static or cached page is enough; it just has to load.

Hosted or self-hosted

Hosted examples include Atlassian Statuspage, Instatus and Better Stack. Popular open-source options are Uptime Kuma, Gatus, Upptime and Cachet. For a small team, a hosted service or Upptime (which runs on GitHub Pages and GitHub Actions) is usually the lowest-effort choice.

Connect it to uptime monitoring

A status page updated only by hand is often late. Link it to monitoring:

1. Set up external checks (HTTP, TCP, ping, keyword) from several locations for each component.
2. Require confirmation from more than one location or several failed checks before changing status, to avoid false alarms.
3. Let monitoring switch the component status automatically, or create a draft incident that a person confirms.
4. Send alerts to the on-call team at the same time, so the page and the people react together.

Automatic status changes are great for clear failures. The text of an incident is still better written by a person.

How to write incident updates

Use a predictable flow: Investigating → Identified → Monitoring → Resolved.

Rules for each update:

• Say what users experience, not internal causes: "Some payments fail with an error" instead of "DB replica lag".
• State the scope: which component, which region or group of users.
• Give the next update time: "Next update in 30 minutes", and keep that promise even if nothing changed.
• Do not promise a fix time unless you are confident.
• After resolving, add a short summary: what happened, how long it lasted, what you will change.

Example:

Investigating: Some users cannot log in to the mobile app. The website works normally. We are looking into the cause and will post an update within 30 minutes.

Common mistakes

• Status page on the same server as the product.
• Showing "All systems operational" while users are already complaining.
• Silence for hours between updates.
• Technical jargon that customers cannot interpret.
• Deleting old incidents to look better.