Tutorials

Setting Up a Public Status Page (And Why It Builds Trust)

Admin User · May 22, 2026 · 9 views

A public status page is one of those small features that makes you look more professional than you might be. It tells your users, clients, or customers what's working and what isn't, without them having to email you to ask. It's also a feature most people don't think to set up until they need it.

Status pages are useful in a few specific scenarios:

  • You run an agency and your clients want to know their sites are being monitored
  • You're a SaaS founder and need to communicate uptime to paying users
  • You manage multiple internal services and want one place to check them all
  • You're the sysadmin friend everyone asks "is the site down" and you'd rather just send them a link

WebMon includes public status pages on the affLIFT plan and above. Here's how to set one up and what to put on it.

Setting It Up

Status pages are configured per user, not per monitor. You pick which monitors to include and the page shows the current status of all of them in one place.

Head to your profile settings and find the Status Page section. You'll see options for:

Page name. Whatever you want to call it. "Client Name Status" or "MyApp Status" works. Make it clear what's being monitored.

Token-based URL. Your status page lives at a URL like webmon.site/status/{your-token}. The token is randomly generated and unguessable, so people who don't have the link can't find your page through search.

Which monitors to include. Tick the ones you want public. You can keep some monitors private (internal services, dev environments) and only show production-facing things on the status page.

Display options. Choose whether to show response times, uptime percentage, and incident history. For client-facing pages I usually show all three. For internal-team pages I might hide the URLs themselves to keep them secret.

Optional password protection. If you want a status page that's not entirely public, you can put a password on it. Good for internal team status or client pages where you don't want competitors knowing what stack they're using.

What Good Status Pages Show

A useful status page answers three questions immediately:

  1. Is the thing I care about working right now? Big green or red indicator. No ambiguity.
  2. If it's not working, when did it break? Timestamp and brief description.
  3. What's the historical pattern? Recent uptime, recent incidents.

WebMon's status pages cover all three by default. Each monitor shows its current status, recent uptime percentage, and recent incidents.

What Status Pages Are For (Beyond the Obvious)

There's an obvious use case (telling people whether the site is up). But status pages do a few less obvious things too.

They reduce support load. If something is broken, half your inbound support tickets will be variations of "is the site down". A status page lets you point everyone to one URL and stop answering individually.

They build trust during outages. Counterintuitively, transparently showing problems makes users trust you more, not less. Hiding outages doesn't make them not happen, it just makes you look incompetent or evasive when users find out anyway.

They give you a paper trail. When a client asks "how often is my site actually down" you can point at the status page history rather than reconstructing it from memory. This has saved several conversations from going badly.

They demonstrate that you're monitoring at all. Some clients assume you're not actually checking their site between visits. A status page shows them you are, in detail, all the time.

What Not to Put on a Public Page

A few things you probably don't want to share publicly:

Detailed error messages. "Database connection failed at 04:31:18" is great for you and useless or worrying for users. Generic "service degradation" is fine for the public page.

Internal monitor names. "Customer Database (legacy)" is your business. Public-facing names like "Account Management" are friendlier and don't reveal architecture.

Things you can't fix. Don't add monitors for services you don't control unless you can also resolve issues with them. A status page that's red for things you can't fix just makes you look bad.

When to Set It Up

Don't wait for the first outage to set up your status page. The worst time to be configuring a new system is when something is on fire. Set it up now while everything is calm. Test it with a real outage scenario by toggling a monitor off and seeing what users would see.

Then forget it exists. That's the goal. A status page is a thing that runs in the background and only becomes useful when needed.

Public status pages are included on the affLIFT plan and above. Manage yours from your profile.

Monitor Your Website Today

Free uptime monitoring with instant alerts. No credit card required.

Get Started Free