Building a public status page strategy

When your service goes down, users have two options: flood your support inbox asking whether it's a them-problem or a you-problem, or check a status page that tells them instantly. Status pages are one of the highest-ROI investments in customer trust — they cost almost nothing to maintain and pay dividends every time something goes wrong.

Why status pages matter

• They immediately answer 'is it down for everyone or just me?' — the most common user question during an incident
• They reduce support ticket volume by 30–50% during outages
• They show customers that you take reliability seriously and communicate proactively
• They give your team a forcing function to communicate clearly and quickly during incidents
• Users remember how you handled an outage more than the outage itself

What to show on a status page

A well-designed status page answers three questions: what is the current state of each component, what has happened recently, and when was this last updated?

• Current status per service component (API, Dashboard, Alerting, Webhooks)
• Active incident banner if something is currently degraded or down
• Incident history with timestamps and resolution notes
• Overall uptime percentage for the past 30, 60, or 90 days
• Last checked timestamp so users know the data is live

Designing for incidents, not normal days

Most of the time, your status page will simply show green. But its real job is incident communication — and under stress, simplicity matters. Design for the 2am incident where your on-call engineer needs to post a quick update and your users need to understand the situation at a glance.

• Use plain language: Operational, Degraded, Partial Outage, Major Outage — no technical jargon
• List components separately so users of unaffected services know they're fine
• Show timestamps in relative time (e.g. '4 minutes ago') alongside absolute time
• Keep the page lightweight — if your CDN is struggling, your status page should still load fast

Choosing your slug

Your status page URL should be short, recognizable, and easy to type — especially when users are frustrated during an outage and trying to find it quickly.

• Keep it to 1–2 words: your brand or product name
• Use lowercase with hyphens: my-company or myapp-status
• Avoid numbers, version strings, and underscores
• Make it obviously related to your main domain or product name

Good examples: acme-api, myapp, build-monitor. Bad examples: production-monitoring-service-v2, 1234abcd.

Communicating during an incident

A status page is only as valuable as the updates you post to it. The gold standard: acknowledge within 5 minutes, post a brief update every 15–30 minutes while investigating, and close with a resolution message explaining what happened and what prevents a recurrence.

'We are investigating increased error rates on the API. More updates in 15 minutes.' is infinitely better than silence. You don't need to have all the answers in the first update.

Setting up with UptimeWiz

1. Create or edit a monitor in the dashboard
2. Scroll to Status Page settings
3. Enter a custom slug (e.g. my-app)
4. Save — your status page is immediately live at /status/your-handle/my-app
5. Share the URL in your docs, error pages, and support auto-responder