What is a status page (and why you need one)?

When something breaks, everyone affected asks the same three questions: is it down, is it just me, and is anyone fixing it? A status page answers all three without a support ticket, a tweet or a reply-all. This explainer covers what belongs on one, why even small products benefit, and how to run one well when things actually go wrong.

The plain-English answer

You have almost certainly used one. When a big provider has a wobble, the first thing engineers everywhere do is open that provider's status page. The pattern is so useful that it has become an expectation: if you run anything other people depend on, sooner or later someone will go looking for yours.

What a status page shows

The format has converged across the industry, and for good reason: a visitor in a hurry should understand the state of your service in about three seconds. A typical page looks like this:

Top to bottom, the standard ingredients:

• An overall banner. One line that rolls every component up into “All systems operational”, a partial outage or a major outage. This is the three-second answer.
• Components with live states. The service broken into the parts users recognise (website, API, dashboard, checkout), each marked operational, degraded, in maintenance or down. Name them in your users' words, not your architecture's.
• Uptime history. Per-component day-by-day bars and an uptime percentage over a selectable window, so a visitor can see whether today's incident is a blip or a pattern. (What counts as a good number is its own topic; see what is a good uptime percentage.)
• Incidents and maintenance. Open incidents with their current state, scheduled maintenance announced ahead of time, and a dated history of both once resolved.
• A subscribe box. Visitors leave an email address or phone number and get told when something breaks and when it's fixed, instead of refreshing the page.

Why you need one

The argument is not aesthetic. It's arithmetic. During an outage, every affected user has the same question, and without a status page the only place to put that question is your inbox:

Beyond the quieter inbox, a status page earns its keep three more ways:

• It builds trust, especially when things break. Outages happen to everyone; what users remember is whether you acknowledged the problem quickly and told the truth about it. A visible, honest incident history reads as operational maturity, and enterprise buyers increasingly check for exactly that during procurement.
• It gives everyone one source of truth. Support points tickets at it, sales sends it to nervous prospects, and your own team checks it before blaming their wifi. “See the status page” replaces a hundred parallel conversations.
• It works when your product can't. A status page hosted on separate infrastructure stays reachable while your site is down, which is precisely when it matters. If the page runs on the same servers as production, it shares production's fate.

Running one during an incident

A status page is at its most valuable in the first hour of a real incident, and what separates a reassuring page from an infuriating one is mostly cadence. The industry has settled on a simple vocabulary for the lifecycle: investigating, identified, monitoring, resolved. Here is what a well-run incident thread looks like:

The habits that make updates like these work:

• Acknowledge fast, even with nothing to say. “We're investigating elevated error rates” posted in minute five beats a perfect explanation posted in minute forty. Silence is what drives people to your inbox.
• Promise the next update, then keep the promise. “Next update within 15 minutes” buys you 15 calm minutes. Missing it costs more trust than the outage itself.
• Say impact in user terms. “Around 20% of API requests are timing out” is useful; internal component names and stack traces are not.
• Close the loop. Mark it resolved, say for how long it was stable first, and follow up with a short write-up for anything significant.

Manual pages vs monitoring-driven pages

There are two ways a status page learns that something is wrong, and the difference decides how much work it is to run.

A manual page is a communication tool only: nothing changes until a human logs in and posts. That gives you total editorial control, but it has a structural flaw. The moment it must update is the exact moment your team is busiest, and a status page that still says “operational” twenty minutes into an outage is worse than no page at all. Users can see it isn't true.

A monitoring-driven page is wired to the same checks that watch your service from the outside (see what uptime monitoring is for how those work). When a monitor confirms a failure, the page flips to investigating on its own; when the check recovers, the incident resolves and subscribers hear about both. 247Monitor's status pages work this way: components are your monitors, renamed for a public audience, and the incident feed is generated from what the monitoring actually observed. You choose how much detail is published, from a generic “we're investigating” to the full cause, and scheduled maintenance windows appear on the page automatically with their start and end times.

Public, private, and your own domain

One format, three common configurations:

• Public is the default and what most products need: a page anyone can open, at a URL like status.247monitor.net/your-page, linked from your site footer and your support macros.
• Private pages are for internal platforms, agencies reporting to clients, or anything you'd rather not show the whole internet. Access works through verified subscribers: a visitor proves control of an approved email address or phone number and gets a time-limited session. On 247Monitor, private pages are included from the Pro plan.
• Your own domain puts the page at status.yourcompany.com with a single CNAME record, with HTTPS handled for you; white-labelling also removes the vendor's branding. Both are Business-plan features on 247Monitor, and the custom domain guide walks through the DNS in a few minutes.

Whichever you choose, the page itself stays on the monitoring provider's infrastructure, which is the point: your outage and your outage announcement should never share a blast radius.

Set one up in ten minutes

1. 1

   Create the page

   Name it, pick the URL slug, and add your logo and brand colour so the page is recognisably yours. On 247Monitor the free plan includes one public page, so there's nothing to buy to start.

2. 2

   Add components your users recognise

   Pick the monitors that represent public-facing surfaces and rename them for the audience: Website, API, Dashboard, Checkout. Leave internal plumbing off the page; nobody outside needs a row for your job queue.

3. 3

   Choose what history to show

   Turn on uptime bars and the percentage if you're proud of the number (and you should aim to be), and pick an incident detail level, from a generic acknowledgement to full causes. Honest defaults age better than curated ones.

4. 4

   Open subscriptions

   Enable email and, if you want it, SMS subscriptions, so users opt into hearing about incidents and recoveries directly. Subscribers confirm before they receive anything, which keeps the list clean.

5. 5

   Put the link where people already look

   Add it to your site footer, your app's help menu, your support auto-replies and your email signatures. A status page nobody can find deflects nothing.

Frequently asked questions

A status page is the cheapest piece of incident response you will ever ship: one honest page that answers “is it down?” so your team can get on with fixing why. 247Monitor includes a monitoring-driven status page on every plan, and if you're weighing up the alternatives, our comparison of free status page tools names the trade-offs honestly.