How to Create a Free Public Status Page for Your SaaS
When your app goes down, users want to know two things: is it just them, and when will it be fixed? A public status page answers both — and cuts support tickets by half. Here's how to set one up in under 5 minutes, for free.
Why a status page matters
Every app goes down. The question isn't whether you'll have an outage — it's whether your users find out from you or from Twitter.
A public status page does three things:
- Reduces support tickets during incidents.Users check the status page, see an acknowledged outage, and wait instead of emailing you. One status page update replaces dozens of individual “is it down?” responses.
- Builds trust with prospective customers. Enterprise buyers and technical evaluators check status pages before signing up. A status page with visible history signals that you take reliability seriously. A missing status page signals the opposite.
- Forces you to monitor your own service.You can't have a status page without uptime monitoring. Setting up a status page is often the trigger that gets indie developers to add proper monitoring for the first time.
What a status page should show
A minimal status page needs three things:
- Current status — operational, degraded, or down. Per-component if your app has multiple services.
- 30-day uptime history — a bar chart showing daily uptime percentage over the last month. This is the single most useful signal for users evaluating your reliability.
- Incident history — past outages with timestamps and resolution notes.
Optional but useful: response time graphs, per-region status, and a subscription mechanism so users can get email or Slack notifications when you post an update.
Option 1: SitePulse (free, 5 minutes)
SitePulse gives you a public status page as part of its uptime monitoring. Every account, including the free tier, gets a status page at sitepulse.satosushi.co/status/your-slug.
How to set it up:
- Sign up at sitepulse.satosushi.co/signup — free, no credit card.
- Add your production URL as a monitor.
- Go to Settings → Status Page. Set your slug (e.g.,
yourapp). Your status page is live atsitepulse.satosushi.co/status/yourapp. - Link to it from your app's footer, error pages, and README.
SitePulse calculates 30-day rolling uptime automatically from probe results. The status page updates in real time as monitors change state. No manual updates needed during incidents.
Option 2: Instatus (free tier)
Instatus is a dedicated status page service with a generous free tier. It supports custom domains, subscriber notifications, and incident management. The free plan covers one status page with unlimited components.
Downside: it doesn't include uptime monitoring. You'll need a separate monitoring tool and manual incident posting — or use their API to automate status updates from your monitoring alerts.
Option 3: Upptime (self-hosted, GitHub Actions)
Upptime runs uptime checks as GitHub Actions and publishes results to GitHub Pages. It's free if you're within GitHub Actions limits, and it's open source.
Downsides: GitHub Actions has a 6-minute minimum interval for scheduled workflows (5 minutes is the documented minimum but doesn't reliably run more frequently than every 6-10 minutes). You can't get 1-minute checks. Setup requires more configuration than a hosted option.
Option 4: Build your own
If you want full control, you can build a minimal status page in a few hours:
- A cron job (or Vercel Cron) that pings your URLs every minute
- A database table storing check results with timestamps
- A public page that queries the last 30 days of results and renders uptime bars
This is a reasonable weekend project, but you'll spend more time on it than you expect (SSL monitoring, alert deduplication, incident states, email notifications). The hosted options above cover all of this out of the box.
Status page best practices
Post incidents proactively
Don't wait until an incident is resolved to post about it. Post when you detect the problem (“Investigating elevated error rates on /api/checkout”), update as you learn more (“Identified root cause: database connection pool exhausted after deploy”), and close when resolved (“Resolved. Root cause was X. Full post-mortem linked below.”).
Don't fake the uptime numbers
Some teams only add monitors they know are reliable and exclude flaky dependencies from the status page. This is understandable but undermines the point. If your API is unreliable, show it — that's what drives you to fix it.
Link to your status page everywhere
- App footer
- Login page (especially if the error is on your auth service)
- 404 and 500 error pages
- Support email auto-responses
- Documentation site
- README
Use a custom domain
status.yourdomain.com is more trustworthy than third-party.com/status/yourappand works even if the monitoring provider changes their URL scheme. Custom domains for status pages are on SitePulse's roadmap — the current URL is free and stable on all plans.
What good looks like
The SitePulse status page itself lives at sitepulse.satosushi.co/status/sitepulse. It shows live monitor status, response time, and 30-day uptime history for the SitePulse service itself. That's the bar — simple, honest, real data.
Frequently asked questions
Do I need a status page if I'm a solo developer?+
Yes, especially if you're a solo developer. When your app goes down, users will tweet, email, and message you asking if it's just them. A public status page with a real-time indicator cuts that noise dramatically — users check the status page first, see an acknowledged incident, and wait instead of flooding your inbox. It also signals professionalism that punches above a solo project's weight.
What's the difference between a status page and uptime monitoring?+
Uptime monitoring checks your URLs and alerts you when something goes down. A status page is the public-facing display of that monitoring data — it shows your users your current operational status and historical uptime. They're complementary: monitoring detects and alerts, the status page communicates. SitePulse does both.
Should my status page be on a separate domain?+
Ideally, yes. If your app is down because of an infrastructure failure, your status page hosted on the same infrastructure may also be down. Hosted status pages (like SitePulse's) run on separate infrastructure and stay up even when your app doesn't. A custom domain like status.yourdomain.com is nice but not strictly necessary — the key is external hosting.
How do I notify users of an incident?+
The minimal viable approach: post an update to your status page and link to it in your app's error pages. More proactive: send an email to affected users or post in your community (Discord, Slack, Twitter). SitePulse's status page shows live status and 30-day history — users can bookmark it and check it directly.
What uptime percentage should I show?+
Show whatever is real. Don't hide bad months — users respect transparency more than they punish honest downtime numbers. A status page showing 99.2% uptime with visible incident history builds more trust than a page that only shows green. SitePulse calculates rolling 30-day uptime automatically.
Related
Get a free status page in 60 seconds
SitePulse gives you a public status page with 30-day uptime history on every plan — including free. No credit card required.