A free status page for your SaaS, done properly

Most small SaaS status pages fail the same way. They exist, they say “All systems operational”, and they said that all through last Tuesday’s outage too. This is how to set one up so it stays true without becoming another thing you have to remember.

What a status page is for

It is a single URL you can send someone instead of answering the same question ten times. During an outage your support inbox, your Slack Connect channels and your Twitter mentions all ask the same thing, and every answer you type by hand is a minute you are not spending on the fix. One page, one timeline, one link in your email signature and your app’s footer.

The secondary use is the boring one that closes deals: a prospect checking whether you have been up for the last ninety days. A page with a real history and real, resolved incidents is more convincing than a page that has never had one.

What to put on it (and what to leave off)

List components your customers can name. “API”, “Web app”, “Dashboard”, “Webhooks”, “Billing” — the things they would say when something is broken. Not “redis-cache-2”, not every microservice: internal topology on a public page just gives people more ways to be confused and you more things to keep updated.

• Three to six components. If you cannot explain a component to a customer in one sentence, it belongs in your monitoring, not here.
• Uptime history. Ninety days of daily results says more than any promise you write.
• Maintenance windows. Posted before, not after. A scheduled window turns “you’re down” into “yes, until 03:00 UTC”.
• A way to subscribe. Email with a real confirmation step, so the list is people who asked, and every message can be unsubscribed from.
• Not an SLA. Do not put a number on the page you have no process to defend.

Make it update itself

A page that only a human can change is a page that is wrong exactly when it matters. The fix is to let something that never sleeps flip the switch:

1. 1. A health check. Point a monitor at a URL that touches your database, not a static file. Two consecutive failures — not one — open the incident, so a single dropped packet does not publish an outage.
2. 2. Your existing alerting. Sentry and Grafana already know things your health check never will. Give them a webhook URL so their alert opens the same incident instead of living in a Slack channel.
3. 3. Your deploy pipeline. A failed migration can post an incident with one curl call, and resolve it the same way when the rollback lands.

Then write the human update. Two sentences: what customers can and cannot do right now, and when you will post again. “We are investigating elevated API errors; checkout is unaffected. Next update in 30 minutes.” Post the next one even if the news is “still working on it”, because silence is what makes people email you.

Put it on your own domain

status.yourapp.com is the difference between a status page and a link to some vendor. It is a CNAME and a TXT record, it takes five minutes, and it means you can change tools later without changing the URL your customers bookmarked. Check that your provider includes it free before you commit — several charge for it, and it is the one thing you should not compromise on.

While you are there, drop the SVG badge in your README and your marketing footer. It links to the page, it is honest advertising when you are up, and it is the cheapest way to make the page discoverable before anyone needs it.

What free actually costs elsewhere

Free plans differ in which piece they hold back. Statuspage gives you a good page but no monitoring and no custom domain under $29 a month. UptimeRobot gives you fifty monitors but keeps Slack and your domain on paid plans. Better Stack gives you both and charges for on-call. PagerDuty gives you on-call for five people and has no page at all. The full breakdown, with dates, is on the comparison page.

IncidentFlare exists because a one-to-three person team needs all three pieces and has no budget for any of them: checks, escalation until someone acknowledges, and a page on your domain — free, no card.

The twenty-minute setup

1. 1. Create the page, add three to five components customers would name.
2. 2. Point one monitor at your health endpoint and link it to a component.
3. 3. Add a Slack channel, then a second escalation step to your email ten minutes later.
4. 4. Fire a test alert and acknowledge it. Now you know paging works.
5. 5. Add status.yourapp.com, verify the DNS records.
6. 6. Put the badge in your README and the link in your app footer and email signature.

Questions

Do I need a status page if I have 20 customers?

You need one before you need it. The value is not the page, it is having a URL you can point at during an outage instead of writing the same message to twenty people. Setting it up takes twenty minutes when nothing is on fire and is impossible to do calmly when something is.

Can a free status page use my own domain?

On some tools. Atlassian Statuspage charges $29 a month for it, UptimeRobot puts it on a paid plan, Better Stack and IncidentFlare include it free. It matters more than it sounds: a link on someone else's domain looks like a third-party outage board, not like you.

Should the page update automatically?

The status should, the words should not. Let a health check flip a component and open the incident, so the page is never lying while you sleep. Write the human sentence yourself when you know something — automated text during an outage reads like a robot avoiding the question.