Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
To create a status page, pick the services you want to show, connect them to the monitors that already watch each one, brand the page with your logo and a custom domain, and turn on subscriber notifications so customers hear about incidents from you first. The key decision is to power the page from real monitoring rather than manual toggles, so it updates itself the moment something breaks. This guide walks through building a status page step by step.
Step 1: Decide what to show
A good status page lists the services your customers actually care about, described in their language, not your internal architecture. Instead of "postgres-primary" and "worker-queue-3," list components like "Website," "API," "Dashboard," "Email delivery," and "File uploads." Aim for a handful of meaningful components. Too many and the page becomes noise; too few and an outage in one area looks like everything is down.
For each component, you will attach one or more monitors. The homepage component maps to your uptime check on the site; the API component maps to your API monitor; and so on. This mapping is what makes the page accurate.
Step 2: Connect monitors so the page updates itself
This is the step that separates a status page that tells the truth from one that lies. Rather than a page you toggle by hand, connect each component to the monitor that watches it. When a check fails, the component flips to "degraded" or "down" automatically; when the check recovers, it flips back. In Uptimehub the status page is generated directly from your monitors, so this wiring is the default rather than something you build.
The payoff shows during a real incident. At the exact moment customers start noticing a problem and hitting your support channel, the page already reflects it, without anyone on your team needing to stop firefighting to update it.
Step 3: Brand it so it feels like your product
A status page is a customer-facing surface, so it should look like part of your brand, not a generic vendor template. Configure:
- Logo and colors so the page matches your site.
- A custom domain such as
status.yoursite.com, set up with a simpleCNAMErecord, so the URL is yours. - A clear title and description that tells visitors what they are looking at.
Branding matters more than it seems. Customers trust a status page at status.yoursite.com far more than one on a third-party domain, and a branded page reinforces that you take reliability seriously.
Step 4: Show uptime history
Turn on the rolling uptime history, typically 30, 60, or 90 days. This is powerful for trust: a component that has been operational 99.98 percent of the time for 90 days tells a stronger story than any marketing copy. Because the history is computed from your actual checks, it is honest data, and honest data is exactly what builds credibility with prospects doing due diligence.
Step 5: Enable subscriber notifications
Let customers subscribe to the page so they are emailed automatically when you post an incident or a component goes down. This is a support-load reducer: subscribers get proactive updates instead of opening tickets to ask "is it just me?" It also sets expectations, since a customer who was notified of an incident and its resolution is far less frustrated than one left guessing.
Step 6: Write incident posts during an outage
Automatic status flips tell customers that something is wrong. Incident posts tell them what is happening and that you are on it. A good incident update follows a simple timeline:
| Stage | What to say |
|---|---|
| Investigating | We are aware of an issue affecting X and are looking into it. |
| Identified | We have found the cause and are working on a fix. |
| Monitoring | A fix is deployed and we are confirming recovery. |
| Resolved | The issue is resolved. Here is a short summary of what happened. |
Keep updates short, honest, and free of blame. Customers remember how you communicated during an outage far longer than they remember the outage itself.
Step 7: Test before you need it
Do not let the first real incident be the first time the page updates. Trigger a test failure on a non-critical monitor, confirm the component flips and subscribers receive the notification, then resolve it. Verify the custom domain resolves over HTTPS and that the certificate is valid. Ten minutes of testing now saves a scramble later.
Step 8: Link to it and keep it current
Put a "Status" link in your footer, your help center, and your error pages, so customers can find it without searching. During calm periods, the page quietly builds trust with a green history; during incidents, it absorbs support load and communicates. Because it is powered by your alerting and monitors, it stays current with no ongoing effort.
Wrapping up
Creating a status page is mostly about one good decision: power it from real monitoring so it updates itself, then brand it, add history, enable subscribers, and communicate clearly during incidents. Uptimehub generates a branded status page with a custom domain and 90-day history directly from your monitors on every plan. See how it works or the pricing page to set one up.
Know your site is down before your customers do
Start monitoring your sites, APIs and services from six regions, with alerts by Slack, email, SMS and webhook and a branded status page. Transparent, flat pricing per monitor.