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.
Before any of that: where the page is hosted
One decision decides whether the page works at all, and it is not a feature. A status page has to survive the failure it reports on. If it runs on the same servers, behind the same load balancer, under the same DNS zone or through the same CDN account as the product, then the outage that takes down the product takes down the page that was supposed to explain the outage.
This is not hypothetical. It is the single most common way a status page fails to do its job, and it is invisible until the day it matters, because in every test you run the product is up.
| Shared dependency | What takes the status page down with the product | How to avoid it |
|---|---|---|
| The same server or cluster | Anything from a full disk to an out-of-memory kill takes both, since they are the same machine | Host the status page on separate infrastructure, ideally with a different provider |
| The same DNS zone | If the zone stops answering, status.yoursite.com stops resolving exactly when people go looking for it | Accept the trade-off knowingly, or use a status URL on a domain you do not use for the product |
| The same CDN or WAF account | An account level problem, an expired card or a misapplied firewall rule affects every property in the account | Separate account, or a status page hosted by a vendor with its own edge |
| The same TLS certificate or renewal job | A renewal that silently fails takes out both hostnames on the same day | Separate certificates, and monitor the expiry date rather than trusting the automation |
| The same authentication or database | A status page that queries your production database to render is offline whenever the database is | Render from static data or from a monitoring system outside your stack |
The DNS row is the one people get wrong most often, because a CNAME on your main zone feels like the obvious way to get a branded URL. It usually is the right call, since the trust gained from a branded domain outweighs the risk for most teams. Just make the trade knowingly, and know that a DNS-layer outage is one of the few where your status page will be gone too. Working out which layer actually failed is a separate exercise, and one a checker that tests DNS, the connection and the certificate separately answers in a single request.
Build your own or use a hosted status page
Three options, and the middle one is where most of the money in this category is.
| Build it yourself | Display-only hosted page | Monitoring-backed page | |
|---|---|---|---|
| What it is | A static page on separate hosting that you edit and redeploy | A hosted page you update by hand or through an API | A page generated from the checks that already watch your services |
| Who updates it | You, during the incident, from a laptop | You, during the incident, from a phone | The monitors, the moment a check fails |
| Cost | Near zero in money, real in engineering time | A separate subscription on top of monitoring | Usually bundled with the monitoring you already pay for |
| Main failure mode | Nobody remembers it exists until an incident, then nobody remembers how to deploy it | The page says operational for the first twenty minutes of an outage because everyone is firefighting | A misconfigured monitor flips a component for a problem customers never saw |
| Best for | Side projects and internal tools | Teams whose incident process is already disciplined | Anyone who wants the page to be right without someone remembering to make it right |
The distinction worth internalizing is that several well-known status page products do no monitoring at any tier. They are a publishing surface: they show whatever you tell them to show. That is a legitimate product, and it means the page is only as current as the person updating it. Our comparison of status page software sets out which tools fall into which camp along with verified pricing.
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.
The translation is the work. Here is what it looks like in practice:
| What you call it internally | What to put on the status page | Why |
|---|---|---|
| postgres-primary, redis-cache, worker-queue | Dashboard | Customers do not know or care which component failed. They know whether the thing they were doing worked. |
| api-gateway, auth-service | API | Split these only if customers integrate with them separately and would want different notifications. |
| ses-relay, transactional-mailer | Email delivery | Worth its own component: email failures are silent to the customer until they notice something never arrived. |
| cdn-origin, asset-pipeline | File uploads and downloads | A named component here prevents a wave of tickets that all say the site is broken when only uploads are. |
| marketing-site | Website | Separate from the product, because these usually run on different infrastructure and fail independently. |
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.
How often to post updates during an incident
Post on a schedule, not when there is news. The instinct during an incident is to wait until you have something concrete to say, which means the page goes quiet for forty minutes exactly when people are refreshing it hardest. Silence reads as nobody is working on this.
A workable default: acknowledge within five minutes of confirming the problem, then update at least every 30 minutes until it is resolved, even when the update is "still investigating, no new information, next update in 30 minutes". Naming the time of the next update is the single highest-value sentence in incident communication, because it converts an open-ended wait into a defined one and stops people checking every two minutes.
Write the resolved post the same day, while you still remember the detail. A short, factual summary of what happened and what changed so it does not happen again is what turns an outage from a trust deficit into evidence that you handle things well. Vague resolutions read worse than the incident did.
Should you publish an uptime percentage?
Publishing a number is good for trust and it invites scrutiny, so publish it only if you can defend how it was calculated. Two services can both honestly display 99.9 percent while measuring completely different things.
- Basis. A 30 day month and a calendar-average month give different allowances for the same percentage, and both are in common use. Say which you use.
- Maintenance. Excluding scheduled maintenance is standard practice and it materially changes the number. If you exclude it, say so on the page.
- Measurement point. A percentage from your own internal telemetry is not the same as one measured by an external check that has to cross the public internet, and the external number is always lower.
- Window. A rolling 90 day figure recovers from a bad month; an all-time figure never does. Neither is dishonest, but they tell very different stories after an incident.
Whatever you choose, keep the arithmetic straight, because a prospect doing due diligence will check it against the incident history right there on the same page. The uptime calculator has the allowance for every percentage across each period if you want to sanity check what your own number implies.
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.
Common questions
Do I really need a status page? If customers pay you and would notice an outage, yes. The test is simple: during your last incident, did anyone email to ask whether it was just them? Every one of those emails is a ticket a status page would have absorbed, and the page also gives your support team one link to send instead of writing the same update repeatedly.
Should a status page be on a subdomain or a separate domain? A subdomain such as status.yoursite.com is what customers expect and what they trust, so it is the right default. The cost is that it depends on your DNS zone, so a DNS-layer failure takes both down. Teams that care about that case keep a second, plainly named address on unrelated DNS and mention it in outage emails.
What should a status page include? At minimum: current status per customer-facing component, an incident feed with timestamps, uptime history over a rolling window, and a way to subscribe. Anything beyond that is optional. A scheduled maintenance calendar is the most useful addition, because it stops planned work generating incident reports.
How much does a status page cost? It ranges from bundled at no extra charge with monitoring, through roughly the price of a second SaaS subscription for a standalone hosted page, to four figures a month at the enterprise end of the dedicated products. The pricing question worth asking is what is metered: subscribers, components and team seats are all common meters and they scale very differently.
How do I make the status page update automatically? Attach each component to the monitor that watches it, so the check result drives the component state rather than a human toggle. This is the difference between a page that is right at 3am and one that is right whenever someone logs in. It is also why a status page that comes with monitoring behaves differently from one that only publishes what you type into it.
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.