How to set up a status page customers actually trust

What a good status page shows, why it should update itself from monitoring, and how to add your own domain, email subscriptions and maintenance notices.

· 4 min read · By the Spot Downtime team

When something breaks, your customers ask one question: is it me, or is it you? A status page answers it before they write to support. It cuts the flood of “is it down?” tickets during an outage, and on a normal day a long run of green bars quietly shows that you take reliability seriously.

Here's how to set one up that people actually trust, and the decisions that make the difference.

What a good status page shows

  • An overall status at the top: operational, partial outage, major outage or maintenance, readable in one second.
  • Your services, in customer terms: “Website”, “API”, “Dashboard”, “Email delivery”. Not “prod-db-02”.
  • History: daily uptime bars for the last 90 days. A page that only shows “right now” can't build trust.
  • Incidents with updates: what happened, what you did, and when it was resolved.
  • Planned maintenance, announced ahead of time.
  • A way to subscribe, so people hear about problems without refreshing the page.

The decision that matters most: automatic or manual?

Many status pages are updated by hand. That means during an outage, someone has to remember, log in and flip a switch, usually while fighting the outage. The result is the most damaging status page there is: “All systems operational” while customers stare at error pages.

Connect the status page to your monitoring instead. When a check fails, the affected service turns red on its own within a minute or two; when it recovers, it goes green. Your team then adds the human part: written updates about what's going on.

Automatic status, human words

Let monitoring decide whether something is down. Let people explain why and what's next.

Choosing what to show

Group by what customers use

Customers don't care about your architecture. If the login service and the database both have to work for “Sign in” to work, show one service called “Sign in” or “Dashboard”, monitored by a check on the real login page.

Keep internals private

A public page shouldn't reveal internal hostnames, IP addresses or raw error messages. Show friendly names and status; keep the details for your team.

Fewer services, clearly named

Five to ten services is plenty for most products. A wall of forty components hides the one that matters.

Setting one up in Spot Downtime

  1. Add monitors for what customers use: the website, the API, the login page, and any important background jobs.
  2. Open Status pages → New status page, pick a title and an address, and choose which monitors to show. Give each a customer-friendly display name.
  3. Publish it. It updates on its own as your monitors run, shows 90 days of daily uptime bars, and never shows URLs, hosts or error details.
  4. Share the link: in your app's footer, your help center, your support auto-replies, and your error pages.

Your first status page is included in every plan, including Free. Starter includes three, Pro ten.

Put it on your own domain

status.yourcompany.com is where customers will look first, and it reassures them they're in the right place. It takes one DNS record, and the HTTPS certificate is issued for you. Starter includes one custom domain; Pro includes one per status page. The custom domain guide walks through the DNS setup, including Cloudflare.

Let people subscribe

Email subscriptions turn your status page from something people check into something that tells them. Visitors enter their email, confirm it with one click (so nobody can be signed up by someone else), and from then on receive:

  • The public updates your team posts on incidents and maintenance.
  • Optionally, automatic emails when a service goes down and when it recovers. Turn this on per status page.

Every email has a one-click unsubscribe link. You can see your subscribers, remove them, or export them as CSV.

During an incident

The page turns red automatically; your job is the words. Post a first update within minutes, then update at the times you promise. Each update can be public, shown on the page and emailed to subscribers, or an internal note for your team. Our guide to writing incident updates has templates for every stage.

Planned maintenance

Schedule maintenance windows ahead of time. They appear on the status page as upcoming maintenance, subscribers can be emailed about them, and the monitors involved pause during the window, so planned work doesn't count as downtime or wake anyone up.

  • Services have customer-friendly names
  • Status comes from monitoring, not a manual switch
  • History is visible (and honest)
  • Subscriptions are on
  • It's on your own domain, or at least linked from your site and app
  • Your team knows how to post an update

See status pages, or create yours free. It takes about two minutes once your monitors are running.

Keep reading