When something breaks, your customer does one of three things. They wait a minute and try again. They check somewhere for confirmation that it's not just them. Or they give up and email support.

Your status page exists to catch them at step two. But whether it succeeds depends entirely on whether it shows them what they came looking for.

Most status pages are built from the inside out — based on what the team wants to show, what the infrastructure team is comfortable exposing, what marketing thinks looks good. The best ones are built from the outside in, starting from a simple question: what is the customer actually trying to find right now?

What They Came For

A customer visits your status page at a specific moment: something isn't working, or they suspect it might not be. In that moment, they want three things, in this exact order.

First, validation. They want confirmation that the problem they're experiencing is real, and not something they broke. Your status page's job is to tell them "yes, we see it too" as fast as possible.

Second, scope. Is it everyone, or just them? Is the whole product down, or just one feature? This determines whether they keep working or go do something else for an hour.

Third, timeline. When will it be fixed? Or at least: when will we hear more? Nobody expects an exact ETA during an active incident. But they need to know if they should wait ten minutes or come back tomorrow.

That's the entire hierarchy. Everything else on your status page is secondary.

What They Don't Want

It's easier to see what belongs on a status page by first noting what doesn't.

Marketing messages. If your status page header says "Join 10,000 teams who trust us!" during an outage, you're reading the room wrong. This is a page people visit when things are broken. Sell somewhere else.
Technical jargon. "Replication lag exceeded threshold" tells your engineering team something useful. It tells your customer nothing. Write for the people affected.
Apologies without updates. "We apologize for the inconvenience" with no new information is worse than silence. It signals you want to look responsive without actually being responsive.
Promises you can't keep. "Service will be restored by 3 PM" is a contract. If 3 PM comes and goes, you've made the problem worse, not better.

Every one of these comes from writing the page for the wrong audience.

The Sequence Matters

Imagine a customer hitting errors for five minutes. They think "something's weird, let me check." They find your status page. Here's what they want to see, in order, without scrolling or searching:

A clear overall status at the top. Not a clever phrase — a clear signal. "Operational" or "We're investigating issues." One glance.
Which specific components are affected. If login is down but the dashboard works, say so. Customers will structure their next hour around this.
The most recent update. Timestamped. In plain language. Short.
A subscribe option so they don't have to check again.

Most status pages get items 1 and 2. They often bury 3. And they sometimes forget 4 entirely, which is a huge miss — the subscribe option is the only way a customer can stop worrying. Subscribers don't have to refresh. They get notified when it's fixed. They can close the tab and trust that you'll tell them.

That subscribe button does more work for customer trust than anything else on the page.

What They Want Before an Incident

The clever thing about status pages is that they also serve customers who aren't currently experiencing a problem. Two types visit the page when nothing is broken:

Prospects evaluating your product. They want to know: does this team take reliability seriously? A status page with 90 days of uptime history and a handful of resolved incidents tells them "yes, things occasionally break, and we handle it professionally." A status page with no history tells them "we just set this up and don't know what we're doing." A status page with zero incidents for six months looks suspicious — nobody has that track record, which means they're hiding incidents.

Existing customers doing due diligence. They might be checking during contract renewal, or before migrating more of their workflow onto your product. They want to see the same thing: an honest track record.

For both groups, the valuable content isn't the current status. It's the history. Which means uptime charts, past incidents, and maintenance logs are doing actual work even when nothing is broken.

What They Want After an Incident

Once something is fixed, a certain segment of your customers still cares. Not many — most go back to work and forget about it. But the ones who stuck around through the incident want to know what actually happened.

A resolved incident page should answer:

What broke? In plain terms. "Our API returned errors for 40 minutes."
Why? Briefly. "A database failover took longer than expected after a configuration change."
What's different now? Reassurance that the same thing won't happen Tuesday.

This is a postmortem, and even a short one builds trust. It tells the customer "we understand what happened and we've taken it seriously." Most small teams skip postmortems, which is a missed opportunity — your most engaged customers are reading them, and they're deciding whether to keep trusting you based on what they find.

The Real Test

There's a simple way to judge whether your status page is doing its job. Ask a customer who's hit an outage: "Did the status page help?"

If they say "yes, I checked and saw you were on it, so I went back to work" — that's success. The page did exactly what it was supposed to do.

If they say "I checked but couldn't tell what was happening" — your updates aren't specific enough, or your overall status isn't clear enough.

If they say "I didn't know you had one" — your status page isn't discoverable from your app, and that's a separate problem to fix before you worry about the content.

The status page isn't a dashboard for your team. It's not a marketing surface. It's not a compliance artifact. It's a customer communication tool that happens to be public 24/7. Build it for the person refreshing it during an outage, and everything else falls into place.

PageCalm helps small teams run status pages with AI-powered incident updates that sound human and ship fast. Try it free — no credit card required.

What Your Customers Actually Want From Your Status Page