Status page best practices: components, honest status levels, update cadence and hosting that survives your outage

The core status page best practices are simple to state: list components the way customers experience your product, use a small set of status levels with written criteria, update on a fixed cadence during incidents, announce maintenance in advance, notify subscribers only when it matters, and host the page on a custom subdomain outside your own infrastructure. A status page is only useful if it stays reachable, stays honest and stays current during the exact moments your own systems are failing. The rest of this guide turns each of those points into concrete decisions, thresholds and checks.

If you are still deciding whether you need a status page at all, start with this overview of what a status page is and what belongs on it. This article assumes you have one, or are about to set one up, and want it to work under pressure.

How should you structure components so customers understand them?

The most common mistake is mirroring your internal architecture. Customers do not know what "worker-pool-b" or "pg-replica-eu" means, and they should not have to translate it. Name components after things customers do or touch.

A useful test: could a support agent read the component name aloud to a customer without explaining it? If not, rename it.

Web App
  - Login and authentication
  - Dashboard
  - File uploads
API
  - REST API
  - Webhooks delivery
Integrations
  - Slack integration
  - Billing and payments
Regions
  - EU (Frankfurt)
  - US (Virginia)

Some guidelines that keep the list readable:

• Keep it between roughly five and fifteen components. Fewer hides real problems, more turns the page into noise.
• Group by product area, and add regions only if customers actually choose a region or notice the difference.
• Include third-party dependencies only when customers feel them directly, such as payment processing or email delivery, and name the capability, not the vendor.
• Keep internal services off the page. A queue backlog matters only through its effect, for example delayed webhook delivery.

Map each public component to the internal checks behind it. That mapping lives in your runbook, not on the page, and it lets the on-call engineer decide quickly which component to mark.

Which status levels should you use, and how honest should they be?

Use a small, fixed vocabulary and define each level in writing before you need it. Ambiguity during an incident leads to the worst habit on status pages: everything stays green because nobody wants to be the one who flips it.

A practical set of status levels with example criteria you can adapt:

• Operational: works as expected for nearly all customers.
• Degraded performance: works, but noticeably slower or with occasional errors, for example p95 latency above twice its normal value or error rate above 1% for more than five minutes.
• Partial outage: a feature, region or customer segment cannot complete its main task.
• Major outage: the component is unusable for most customers.
• Under maintenance: planned work, announced in advance.

The numbers are placeholders. Pick values that match your normal baseline and write them into the runbook so the decision is mechanical.

Honesty rules worth adopting as a team:

• If customers are reporting a problem you have confirmed, the page must not say Operational.
• When in doubt between two levels, pick the worse one and downgrade later. Upgrading severity mid-incident looks like you were hiding it.
• Do not post "minor issue" for something that blocks logins. Customers judge severity by their own experience, not by your percentage of affected requests.

Should component status be automated from monitoring?

Partially. Automating clear-cut failures, such as a component failing checks from several regions at once, gets the page to amber or red within minutes instead of whenever someone remembers. Automating everything is risky: a single flaky probe can flip a component back and forth and destroy trust faster than a slow manual update.

A reasonable split is automatic status changes only after confirmation from multiple locations and consecutive failures, with incident text always written by a human. The same techniques that keep alerts quiet apply here, see how to reduce false positive alerts with multi-region checks and retries.

How often should you update the status page during an incident?

Speed of the first post matters more than its completeness. Then a predictable rhythm matters more than the content of each update. Customers refresh the page; silence reads as "they do not know" or "they do not care".

A cadence that works for most small and mid-sized teams:

1. First post within 10 to 15 minutes of confirming customer impact, even if it only says you are investigating and which component is affected.
2. Updates every 30 minutes while the incident is active, even when nothing has changed. "Still working on it, next update at 14:30 UTC" is a valid update.
3. Every update names the time of the next one. This single habit removes a large share of "any news?" tickets.
4. Once a fix is deployed, switch to Monitoring and update every 30 to 60 minutes until you are confident.
5. Post Resolved with the start time, end time and affected components. Add a short follow-up or postmortem link within a few days for anything major.

Assign one person as the communicator for the incident, separate from whoever is debugging. Engineers deep in a fix forget the clock. The wording of each stage is covered in detail in how to write an incident status update, so this article stays with timing and structure.

How should you announce scheduled maintenance?

Planned work is where a status page earns trust cheaply. You control the timing, so there is no excuse for surprises.

• Announce impactful maintenance about a week ahead, with reminders around 24 hours and 1 hour before the start.
• Write times in UTC and, if most customers share a time zone, add that local time too: "Tuesday 03:00 to 04:00 UTC (05:00 to 06:00 CEST)".
• State the expected impact per component: "API read-only, dashboard unavailable, webhooks queued and delivered afterwards."
• Post when maintenance starts and when it ends. If it overruns, convert it to an incident instead of silently extending the window.
• Schedule outside your customers' peak hours, not yours.

Zero-impact maintenance usually does not need an announcement. Posting every routine deploy trains subscribers to ignore you.

How should subscriber notifications work?

Subscriber notifications are the push side of the page. They reach people who will not think to check the page, which is most of them. They also become spam quickly.

Send notifications for:

• a new incident that affects customers,
• a meaningful change in status or scope, such as a partial outage becoming a major one,
• resolution,
• maintenance announcements and their start and end.

Do not send notifications for every 30-minute "no change" update. Those belong on the page, not in inboxes.

Two technical details are easy to overlook. First, confirm subscriptions with a double opt-in and include a one-click unsubscribe, or you will end up with bounced and complaining addresses. Second, check what sends those emails. If notifications go through the same mail setup as your application and that setup is part of the outage, your subscribers hear nothing exactly when they should.

Why host the status page outside your infrastructure and on a custom domain?

A status page that runs on the same servers, cloud account, CDN or database as your product will go down with it. That is the one failure mode you cannot afford. Independent hosting is the best practice that matters most and gets checked least.

Walk through every dependency of the page and ask whether it is shared with production:

• Hosting and region: different provider or at least different account and region.
• DNS: if your DNS provider fails, status.example.com fails too. Know the fallback URL your host gives you and mention it in support docs.
• Assets: no scripts, fonts or images loaded from your main app or CDN.
• Admin access: can the on-call engineer log in to post an update if your SSO, VPN or password manager is down? Keep a tested break-glass login.
• Email: as above, subscriber mail should not depend on your own mail infrastructure.

A custom subdomain such as status.example.com tells customers the page is official and is easy to remember. With a hosted page this is usually a CNAME record:

status.example.com.  3600  IN  CNAME  your-page.status-host.example.

Verify it from outside your network and check that HTTPS works on the custom domain:

dig +short status.example.com CNAME
curl -sSI https://status.example.com | head -n 1

Then run the real test: during a game day or maintenance window, pretend production is gone and try to load the page, log in and publish an update using nothing that depends on your own stack. Monitor the status page URL itself with an external check as well, because nobody notices a broken status page until the day it is needed.

Public or private status page?

Public pages work for most SaaS products and reduce tickets the most. A password-protected page fits internal platforms, single large customers or B2B products where you do not want to expose component names. The same practices apply to both.

A status page best practices checklist

1. Components are named after customer-facing features, five to fifteen in total.
2. Each public component maps to specific internal checks in the runbook.
3. Status levels have written criteria, and the team agrees to pick the worse level when unsure.
4. Automatic status changes require multi-location confirmation; incident text is written by a human.
5. First incident post within 10 to 15 minutes, then updates every 30 minutes with the next update time stated.
6. One communicator per incident, separate from the person fixing it.
7. Maintenance announced about a week ahead with reminders, times in UTC, impact per component.
8. Subscribers are notified on new incidents, major changes, resolution and maintenance only.
9. Page, DNS, assets, admin login and notification email do not share failure domains with production.
10. Custom subdomain via CNAME, verified externally, and the page itself is monitored.

Setting this up with a hosted status page

Any hosted status page service that runs outside your infrastructure can cover most of this checklist. As one option, m0nitor's public status pages show current and historical availability per component, active incidents and scheduled maintenance, and support a custom domain via CNAME, password protection for private pages, email subscribers, multiple languages and a public incident history. Incident templates with placeholders can help keep first posts fast and consistent. The checklist above applies regardless of the tool you choose.

FAQ

What should be on a status page?

Customer-facing components with their current status, active incidents with timestamped updates, upcoming scheduled maintenance, a history of past incidents and a way to subscribe to notifications. Internal service names, raw metrics and vendor names usually do not belong there.

How often should a status page be updated during an outage?

Post the first update within 10 to 15 minutes of confirming impact, then update at least every 30 minutes until the issue is resolved, even if nothing has changed. Always state when the next update will come.

Should a status page be hosted on your own servers?

No. If the page shares hosting, DNS, CDN or login with your product, it can fail at the same time. Host it independently, ideally with a custom subdomain pointing to an external provider, and test that you can publish updates while production is unavailable.

Should status page updates be automated?

Automate component status for confirmed failures detected from multiple locations, so the page reacts within minutes. Keep incident messages human-written, because automated text cannot explain impact, workarounds or next steps in a way customers trust.