What a good public status page looks like

A public status page is where customers go during an outage. A good status page reduces the number of support tickets and builds trust. Here is what it consists of.

What a good status page must have

Current state of every key service. Not just "everything OK", but broken down by component (API, web, dashboard, emailing, payment processing).
Incident history for the last 90 days. Without trying to hide anything - a transparent history builds trust.
Uptime metric (typically over 30 days) for each component, expressed as a transparent percentage.
Scheduled maintenance. A banner with the date and a description of what will be unavailable.
Active incident with a timeline of updates. Investigating → Identified → Monitoring → Resolved.
A subscription form. Customers get an email when the status changes and don't have to check the page repeatedly.

A clear component hierarchy

Instead of a single "monitor" entry, split the service into components that make sense from the customer's point of view:

Web App - frontend (used by visitors)
API - backend for programmatic integrations
Auth / Login - sign-in
Email delivery - transactional emails
Background jobs - sync, billing, exports
Status page - meta component: the status page itself can go down too (which is why it should run on different infrastructure than the product)

Incident communication: anatomy of a good update

During a real outage, follow these phases:

Investigating - "We have identified a problem with [component]. The team is investigating the cause." (within 5 min of detection)
Identified - "The cause is [briefly]. We are working on a fix. ETA [time]." (when you know what is causing the problem)
Monitoring - "We have deployed a fix. We are watching to make sure the problem does not recur." (after deploying the solution)
Resolved - "The incident is resolved. Duration X minutes. A postmortem will follow." (after confirmed recovery)

Each phase gets a timestamp and its own update. After the incident, publish a post-mortem (root cause, timeline and measures that prevent recurrence).

Rule: Never use vague phrases like "experiencing some issues". Customers want specifics: "Login fails on ~30% of attempts. API is working normally. The web is available in read-only mode only."

Hosting: the principle of independent infrastructure

The status page must run on different infrastructure than the monitored service. If your AWS region goes down, a status page hosted in the same region goes down with it - exactly at the moment customers need it most.

Practical solutions:

Hosting via an external SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Your own static page on a CDN (Cloudflare Pages, Netlify) with the API endpoint elsewhere
As a last resort, a minimal static page on Cloudflare with manually updated text

Subscribers: email and webhook

Customers don't want to refresh the status page constantly. A good page therefore supports:

Email subscribers - in ePulz.io available for logged-in users on a paid plan (we only collect subscriptions from verified accounts, not from anonymous visitors)
Webhook - for teams that want to integrate the status into their own Slack or PagerDuty

Anti-pattern: hiding problems

The temptation to mark an outage as "degraded" instead of "down" (or not to show it at all) is strong, but short-sighted:

Customers will notice the outage anyway (through their own monitoring, support tickets or social media)
You lose trust when they find out the status reports "OK" during an obvious outage
You lose the real picture of the uptime trend, which you need for internal decision-making

The best strategy is radical transparency. GitLab, Cloudflare and Stripe all publish detailed post-mortems even for embarrassing mistakes, and the community appreciates it.

SEO and brand

A status page should:

Live on a stable and easy-to-remember URL for the service status
Have its own branding (logo, colors) - the customer must see that they are still on your page
Be indexed in Google (better visibility when searching for "[brand] down")
Be linked from the main site (footer "Service status")

Conclusion

A status page is not decoration. It is an operational tool that reduces support load during an incident and builds long-term trust. Investing a few hours in the right configuration pays off the moment the first major outage hits.

Create a status page in 5 minutes

ePulz.io status pages with custom branding, email subscribers and an incident timeline. 7 days free.

Try ePulz.io →