Back to blog

Status page best practices: how to communicate outages

· 6 min read

In brief: A public status page is the place customers go when something doesn't work for them. A good status page reduces support tickets, builds trust and saves your team from dozens of repeated questions during an incident.

In brief: A public status page is the place customers go when something doesn't work for them. A good status page reduces support tickets, builds trust and saves your team from dozens of repeated questions during an incident.

What a good status page must have

  1. Current state of each key service. Not just "all OK" - split by components (API, web, dashboard, emailing, payment processing).
  2. Incident history for the last 90 days. Without trying to hide them. Honest history builds trust.
  3. Uptime metric (typically over 30 days) for each component. Transparent percentage.
  4. Planned maintenance. Banner with date and description of what will be inaccessible.
  5. Active incident with post-update timeline. Investigating → Identified → Monitoring → Resolved.
  6. Subscribe form - customers get email on state change, don't have to repeatedly check.

Clear component hierarchy

Instead of one "monitor" record split into components that make sense from the customer's perspective:

  • Web App - frontend (visitors use it)
  • API - backend for programmatic integrations
  • Auth / Login - authentication
  • Email delivery - transactional emails
  • Background jobs - sync, invoicing, exports
  • Status page - meta itself - even this can fall (which is why it should be hosted on different infrastructure than the product)

Incident communication: anatomy of a good update

During a real outage follow these phases:

  1. Investigating - "We have identified a problem with [component]. The team is investigating the cause." (within 5 min of detection)
  2. Identified - "The cause is [briefly]. We're working on a fix. ETA [time]." (when you know what's causing it)
  3. Monitoring - "We deployed the fix. We're monitoring whether the problem recurs." (after deploying the solution)
  4. Resolved - "The incident is resolved. Duration X minutes. Postmortem follows." (confirmed recovery)

Each phase gets a timestamp and update. After the incident publish a post-mortem (root cause, timeline, what we're doing so it doesn't repeat).

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

Hosting: principle of independent infrastructure

The status page must run on different infrastructure than the monitored service. If your AWS region falls, your status page hosted on the same AWS region also falls - exactly when customers need it most.

Practical solutions:

  • Hosting via external SaaS (StatusPage.io, ePulz.io, Better Stack, Statuspage)
  • Own static page on CDN (Cloudflare Pages, Netlify) with API endpoint elsewhere
  • Worst case: minimal static page on Cloudflare with manually updated text

Subscribers: e-mail / RSS / webhook

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

  • Email subscribers - in ePulz.io available for logged-in users with a paid plan (we collect subscriptions only from verified accounts, not from anonymous visitors)
  • RSS / Atom feed - traditional way for tech-savvy users
  • Webhook - for teams that want to integrate into their Slack or PagerDuty

Anti-pattern: hiding problems

The temptation is great to mark an outage as "degraded" instead of "down", or not show it at all. That's short-sighted:

  • Customers will notice anyway (own monitoring, support ticket flow, social networks)
  • Loss of trust when they find out the status says "OK" during an evident outage
  • No picture of real uptime trend for internal decision making

Best strategy: radical transparency. GitLab, Cloudflare, Stripe all publish detailed post-mortems even for embarrassing mistakes. The community appreciates it.

SEO and brand

The status page should:

  • Be on own subdomain (status.example.com) or URL prefix
  • Have own branding (logo, colors) - customer must know they're on your page
  • Be indexed in Google (better visibility for "[brand] down" search)
  • Linked from main page (footer "Service status")

Conclusion

A status page is not decoration. It's an operational tool that reduces support cost during an incident and builds long-term trust. Investment of 1-2 hours in proper configuration returns on the first major outage.

Create a status page in 5 minutes

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

Try ePulz.io →

Try ePulz.io free - 7 days, no credit card needed.

Create account