When your app goes down, silence is the worst response. A status page hosted outside your own infrastructure tells people you know what’s broken before they have to ask you directly. That alone cuts support tickets during an incident by a lot — people check the page instead of emailing.

Why not just post on X

Because half your users don’t follow you there, and a tweet disappears in an hour. A status page is a permanent, linkable record: what broke, when, and when it was fixed. Put the link in your footer and your onboarding email so people know it exists before they need it.

Host it away from your own infrastructure

This is the part people get wrong. If your status page runs on the same server as your app, it goes down with your app. Two options that don’t:

Upptime — a status page that runs entirely on GitHub Actions and GitHub Pages. It pings your endpoints on a schedule, commits the results to a repo, and serves a static site from Pages. If your server is down, GitHub still is not.

npx degit upptime/upptime status-page
cd status-page

Edit .upptimerc.yml:

owner: yourname
repo: status-page
sites:
  - name: API
    url: https://api.example.com/health
  - name: Marketing site
    url: https://example.com

Push it, enable GitHub Pages on the repo, and Upptime’s included Actions workflows take over — checks every 5 minutes, incidents auto-logged as GitHub issues, uptime graphs generated as static SVGs.

Uptime Kuma — if you want a dashboard you control instead of static Markdown, self-host it on a separate box or VPS from your main app:

docker run -d --restart=unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

It gives you a status page builder, incident announcements, and notification hooks (Slack, Discord, email, webhook) out of the box. The catch: it’s a real service you now have to keep running. Put it on a different provider than your main app — a $5/mo VPS from a different company is fine. If both run on the same host, your status page goes dark exactly when people need it.

What to put on it

Keep it to three things:

• Current status per component (API, dashboard, webhooks, whatever your users actually depend on separately).
• Incident history — what happened, when it started, when it resolved. Don’t delete old incidents; a page with a spotless history for two years reads as fake.
• Subscribe option — email or RSS, so people don’t have to keep refreshing.

Write the incident update like a human

The instinct during an outage is to say nothing until you have the full picture. Resist it. Post within 10 minutes of noticing, even if the update is just:

Investigating elevated error rates on the API. Update in 20 minutes.

That single line does more for trust than a perfect root-cause writeup three hours later. Follow up when you said you would, even if the update is “still investigating.” Going quiet after the first post is worse than the outage itself — it’s the thing people actually complain about afterward.

The postmortem

For anything that took down the app for more than a few minutes, write a short postmortem: what broke, what you did, what you’re changing so it doesn’t happen the same way again. Two paragraphs is enough. Skip the blameless-culture essay — just the facts and the fix. Users don’t need your internal process, they need to know it won’t happen again next week.

A status page you don’t maintain is worse than no status page — a stale “All Systems Operational” banner during a real outage burns more trust than silence would have. If you’re not going to update it live, at minimum wire the automated checks (Upptime does this for free) so it’s never visibly lying.