Status Pages Done Right: What to Publish in an Outage

A status page is often the only channel customers can reach during an outage - email support is backed up, your app is down, and social media replies take time. What you publish there, and how quickly, shapes customer trust more than the outage itself usually does.

What belongs on a status page

Group components logically, not by internal service names customers won't recognize:

Avoid two extremes: a single "Everything" component that hides which specific feature is affected, and 40 granular components that overwhelm visitors trying to quickly check if the outage affects them.

Status levels that mean something

Use consistent, unambiguous status levels:

• Operational - no known issues.
• Degraded Performance - working, but slower or intermittently failing.
• Partial Outage - a subset of functionality or users affected.
• Major Outage - most or all users affected.
• Under Maintenance - planned, communicated in advance.

Map these directly to your internal severity matrix so there's no translation step during a live incident - see our incident response playbook for how severity tiers should drive both paging and status page updates.

Update cadence during an outage

The single most common status page mistake is going quiet between updates. Even "no new information, still investigating, next update at 15:30 UTC" is better than silence - it signals the team is actively working the problem.

Wording that builds trust instead of eroding it

Avoid vague, defensive language. Compare:

Bad: "We are aware some users may be experiencing issues and are
looking into it."

Good: "The API is returning errors for approximately 15% of
requests since 14:02 UTC. We've identified the cause as a database
connection pool exhaustion and are deploying a fix. Next update in
20 minutes."

Specificity does two things: it proves you actually understand the problem (reducing anxious support tickets), and it gives technical customers enough detail to know whether it affects their integration.

Update template library:

[Investigating]
We are investigating reports of {symptom} affecting {component}
since {time} UTC. Next update within {interval}.

[Identified]
We've identified the root cause as {cause}. A fix is being
{deployed/rolled back/tested}. ETA: {estimate}.

[Monitoring]
A fix has been applied and {component} is recovering. We are
monitoring closely before marking this resolved.

[Resolved]
This incident is resolved as of {time} UTC. Total impact:
{duration}, {affected scope}. A post-mortem will be published
{timeframe} if applicable.

Subscriber communications

Status pages should support multiple notification channels, since customers have different preferences:

• Email digest (default for most non-technical stakeholders)
• Webhook/RSS for integrating into internal dashboards
• Slack/Teams integration for customers who monitor you as a vendor dependency

Subscribers should get notified on: incident opened, each major update, and resolution - not on every minor status tweak, or they'll unsubscribe.

Hosting on a custom domain

A status page hosted at status.yourcompany.com (rather than a generic third-party subdomain) reinforces trust and looks intentional rather than bolted-on. Practical setup checklist:

• Create a CNAME record: status.yourcompany.com → your status page provider's target
• Enable TLS/SSL for the custom domain and verify it auto-renews (a broken cert on your status page during an outage is a bad look)
• Link to the status page from your app's footer, error pages, and support portal
• Host the status page on infrastructure independent from your main product, so it stays up during a full outage
• Set up SSL monitoring on the custom status page domain itself - it's easy to forget and let its certificate lapse silently
• Add the status page domain to your domain expiration monitoring so it can't lapse unnoticed

ServerInspector's status page product supports custom domains, component grouping, and subscriber notifications out of the box, paired with the same uptime monitoring checks that detect the incident in the first place.

Example component + incident layout

Status: Partial Outage

Components:
- Web App .............. Operational
- API .................. Degraded Performance
- Authentication ....... Operational
- Payments (Stripe) .... Operational
- EU-West Region ....... Partial Outage

Active Incident: Elevated API latency in EU-West
Started: 14:02 UTC
Updates:
  14:32 UTC - Monitoring: Fix deployed, latency recovering
  14:15 UTC - Identified: Database connection pool exhaustion
  14:02 UTC - Investigating: Elevated latency detected on EU-West API

What not to publish

• Internal system names or infrastructure details irrelevant to customers (e.g., specific Kubernetes pod names).
• Blame toward a third-party vendor before you've confirmed it publicly with them.
• Overly technical root cause detail in the live incident - save deep technical detail for the post-mortem, published after resolution.
• Exact security vulnerability details during an active security incident, until a fix is deployed.

FAQ

Should a status page be automated or manually updated?

Automated updates from uptime/API monitoring checks are useful for detecting and opening incidents quickly, but the human-written narrative ("we've identified the cause...") should be manually authored - customers can tell the difference.

How many components should a status page have?

Enough to let a customer quickly identify if the specific feature they use is affected - typically 4-8 components for most SaaS products. Fewer than that hides useful detail; more overwhelms.

Do we need a status page if we're a small team?

Yes, arguably more than large teams - small teams have fewer support staff to field "is it down for everyone?" tickets, so a status page directly reduces support load during incidents.

What SSL and domain checks should apply to the status page itself?

Monitor the status page's certificate expiration and domain expiration independently from your main product domain, since it's a separate DNS record and easy to overlook until it fails during the exact outage it's supposed to communicate.

Handling maintenance windows separately from incidents

Planned maintenance shouldn't use the same urgent language as an unplanned outage - customers react differently to "we're upgrading the database tonight" than to "the database is down." Schedule maintenance windows on the status page at least 24-48 hours in advance when possible, with a clear start and end time in UTC, and follow up with an explicit "maintenance completed" update rather than letting the window silently expire.

A simple maintenance announcement template:

[Scheduled Maintenance]
We will be performing scheduled database maintenance on
{date} from {start} to {end} UTC. We expect {impact, e.g.
"no downtime" or "up to 5 minutes of API unavailability"}
during this window. No action is needed on your part.

Integrating the status page with monitoring

The most reliable status pages tie directly into automated checks rather than depending entirely on a human to notice and log in. When an uptime monitoring or API monitoring check fails and is confirmed (not a single flaky probe), it should be able to automatically flip the relevant component to "Degraded" or "Major Outage" and open a draft incident, which a human then edits with narrative detail before publishing. This shortens the gap between real-world failure and the first customer-visible update, which is usually the biggest driver of support ticket volume during an outage.

Post-incident status page hygiene

After resolution, don't just flip the component back to green and move on:

• Leave the resolved incident visible in the history log for at least 90 days - customers auditing your reliability (especially enterprise buyers) look at this history.
• Link the published post-mortem, if one exists, directly from the resolved incident entry.
• Review whether the component granularity was right - if customers kept asking "does this affect X" during the incident and X wasn't its own component, consider splitting it out.
• Confirm subscriber notifications actually sent successfully; a failed notification during a real outage undermines the entire point of having subscribers.

Choosing a status page approach

For most teams past the earliest prototype stage, a dedicated status page product on a custom domain is worth the cost purely for the independence from your primary infrastructure during the exact moment you need it most.