How to set up a status page (best practices)

If you're still weighing up whether you need one, start with what a status page is and why it pays off. This guide is the practical half: the setup, the naming and candour decisions that decide whether people trust the page, and the launch steps most teams skip. This is what you're building:

Decide three things first

Ten minutes of decisions save a relaunch later. Before creating anything, settle these:

• Audience. A public page for customers is the default. Internal platforms and agencies reporting to clients often want a private page instead; that choice changes the plan you need and how people will reach it.
• Scope. Which surfaces deserve a row? The answer is the parts of your product users can point at, not the parts your architecture diagram can.
• Candour. How much should an incident say in public, and do you want uptime percentages on display? Honest defaults age best, but regulated industries sometimes need the terse version.

The basic setup, step by step

1. 1

   Create the page

   Give it a name, a URL slug and your branding (logo and brand colour). On 247Monitor the page lives at status.247monitor.net/your-slug and the free plan includes one public page, so this costs nothing to start.

2. 2

   Add components backed by real monitors

   Each row on the page is one of your monitors, renamed for a public audience. If a surface you want to show isn't monitored yet, create the monitor first; the page can only report what something is actually checking.

3. 3

   Choose the history you show

   Per-component uptime bars and a percentage over a selectable window (24 hours to 90 days) are optional but persuasive; show them if you're proud of the number, and aim to be. For what counts as a good number, see what is a good uptime percentage.

4. 4

   Pick the incident detail level

   Decide how much each incident reveals, from a generic acknowledgement to the observed cause. This is a one-time setting per page; the trade-offs are covered below.

5. 5

   Open subscriptions

   Enable email and, if you want it, SMS subscriptions. Visitors confirm before they receive anything (a verification link or a code), which keeps the list clean, and plans include from 100 subscribers on Free up to 10,000 on Business.

6. 6

   Publish, then smoke-test it

   Open the page in a private browser window, subscribe with a personal address, and check it from a phone on mobile data rather than your office network. You want to see exactly what a stranded user will see.

Name components for readers, not architects

The single biggest quality difference between status pages is the component list. Your monitoring watches infrastructure; your status page talks to customers. The mapping between the two should be deliberate:

• Use your users' vocabulary. Website, API, Dashboard, Checkout. If a name would need explaining in a support reply, it's the wrong name.
• Curate hard. Five rows people understand beat fifteen they don't. Internal services belong in your dashboards, not on the public page; if they fail in a way that matters, users will see it through the surface it breaks.
• Keep rows truthful. Every row is backed by a real check, so the state is what monitoring observed, not what someone hopes. Rename monitors rather than inventing rows nothing is watching.
• Order by importance. Put the surface most users depend on first; alphabetical ordering optimises for nobody.

Choose how much an incident says

When a monitor confirms a failure, the page opens an incident on its own and closes it on recovery, notifying subscribers at both ends. What you control is how much those posts reveal:

For most products, standard or detailed is the right call: naming the affected surface is what makes the page useful, and sharing the observed cause is a trust signal competitors with quiet pages can't match. Choose minimal only when there's a real constraint, and remember the incident history is public memory; a feed of vague acknowledgements reads worse over time than a feed of honest specifics.

Put it on your own domain

status.yourcompany.com looks better in a support reply than a vendor URL, and it survives tooling changes. The mechanics are one DNS record: add a CNAME pointing your chosen subdomain at the provider's target host, wait for DNS to propagate, and HTTPS is provisioned and renewed for you. On 247Monitor this and white-labelling (removing the vendor branding) are Business-plan features, and the custom domain guide walks through the exact record. Two notes: use a subdomain (the apex stays with your main site), and keep the DNS-only setting on if your DNS lives behind a proxying CDN so the record resolves cleanly.

Private pages

Internal platform teams and agencies often need the page without the public. A private page (included from the Pro plan on 247Monitor) gates access through approved subscribers: a visitor proves control of a subscribed email address or phone number and gets a time-limited session. Because access rides on the subscriber list you already manage, there's no shared password to rotate when someone leaves a client team; remove the subscriber and the access goes with them.

Announce maintenance properly

Planned work that looks like an outage costs you twice: once in alerts, once in trust. Schedule a maintenance window instead of just doing the work. The window appears on the status page ahead of time, moves from scheduled to in progress to completed around its start and end times, notifies subscribers when it's booked, and keeps your monitors quiet while it runs so expected downtime doesn't page anyone or open a public incident. Announce even the “invisible” work; the one time a migration overruns, you'll be glad the page already said maintenance was happening.

The launch checklist

A status page earns nothing sitting at an unlinked URL. Before calling it done:

• Link it from your site footer and your app's help or account menu, the two places people look first.
• Put it in support's hands: auto-replies, macros and the help-centre homepage. During an incident, support should be sending the link, not writing summaries.
• Subscribe your own team, including the on-call phone. If the page breaks the news to a customer before your engineers, something is wired backwards.
• Add it to runbooks and onboarding docs, so “check the status page” becomes the reflex inside the company too.
• Revisit after your first real incident. Rename anything users misread, and add the row people asked about. The first incident is the only usability test that counts.

Frequently asked questions

Set up in ten minutes, tuned in one incident: components in user language, honest detail, your own domain, and links where people already look. 247Monitor includes a monitoring-driven status page on every plan, and if you're still choosing a tool, the free status page comparison shows where each option's limits sit.