SaaS Status Page Checklist: What to Publish Before an Outage

A SaaS status page is a public page, hosted away from your app, that tells customers which parts of your product are working, what you are doing about a problem and when you will post next. Set it up before your first outage: list your components, decide your incident states, switch on subscriptions, add a maintenance notice format and keep past incidents visible. Hosted tools such as Atlassian Statuspage, Better Stack, Instatus, Openstatus and UptimeRobot all have free plans, and open-source projects such as Upptime and Uptime Kuma let you run your own.

Disclosure: ZeroRaised publishes this guide and appears in the final section. Plans, prices and features come from each vendor's own pricing page, documentation or GitHub repository as checked on 18 Oct 2026. Prices change, so check the page before you pay. ZeroRaised has no affiliate deal with any tool named here, and this guide makes no promise of uptime, traffic or customers from any tool or launch site.

TL;DR#

A status page is a promise about communication, not about uptime. It earns its keep in the first ten minutes of an outage, when customers would otherwise be emailing you, posting on social media or quietly deciding to leave. All the preparation happens before that: the page, the component list, the subscriber list and the words you will use.

The decision most solo makers get wrong is where the page lives. A status route inside your own app goes down with your app. A separate subdomain pointed at a separate provider does not. On 15 October 2026 Hacker News user mikewww posted a Show HN for AlwaysGreen, a tool that pairs uptime checks with a public status page, a useful snapshot of what its maker thinks the job needs.

What happened: a status page Show HN on 15 October 2026#

On Hacker News, user mikewww posted Show HN: AlwaysGreen, uptime monitoring and status page (title paraphrased slightly). The item page shows a relative age, but the HN item API gives the exact time: 15 October 2026 at 22:30:28 UTC, which is 23:30 BST. It was a small post, and one launch does not tell you what the market wants. It is useful here because the AlwaysGreen landing page spells out what its maker thinks a small team needs from a status page.

The pitch is "Monitoring + status page in one". The page lists checks from multiple regions, Slack and email alerts, "Point status.yourco.com at us with automated TLS", incident updates with subscriber notifications, and a one-click import of "components and historical incidents" from Atlassian Statuspage. Prices on the page as checked on 18 Oct 2026:

• Free, $0 a month: 3 monitors with 5-minute checks, 1 public status page, 50 email subscribers, 30-day history.
• Indie, $9 a month: 10 monitors with 1-minute checks, 1 status page plus custom domain, unlimited subscribers, 90-day history.
• Team, $19 a month: 50 monitors with 30-second checks, 5 status pages with custom domains, branding removed, 1-year history.

Two things in that list match the rest of this guide. The custom subdomain is front and centre, because a status page on its own address is the whole point. And history is a plan feature: the longer you keep past incidents visible, the more the page works as a track record rather than a one-off notice.

Two dated vendor changes from the same weeks point the same way. Openstatus published Maintenance updates on Oct 09, 2026, turning a maintenance notice into a timeline of dated updates, and Incident management on Oct 15, 2026. Neither is a price change; no status page vendor I checked published a dated pricing change on its own site between 18 September and 18 October 2026.

What a SaaS status page is for#

The plain answer: it saves you from writing the same reply forty times while you should be fixing the problem, and it shows customers that someone is on it.

Atlassian, which sells Statuspage, makes the case directly in its incident communication guide: "We recommend teams use a dedicated status page as their primary incident communication solution." It adds that this applies "Whether you build it yourself or use a hosted solution like Statuspage", and that subscriptions take "the support burden off teams who should be heads-down fixing the problem." The same page lists the other channels a team might use: embedded status, email, workplace chat, social media and SMS.

For a solo maker the support point matters most: you fix the database and answer the inbox. A page that customers can check, and an email that goes out to subscribers when you post, turns one update into hundreds of answered questions.

It also does three quieter jobs:

1. It tells customers whether the problem is on their side or yours. A customer who sees a green page knows to check their own network or settings. An open incident tells them to stop troubleshooting.
2. It gives you a record. Past incidents, with dates and causes, show prospective customers how you handle problems. That history is worth more than a promise on a pricing page.
3. It forces you to decide what your product is made of. Listing components makes you think about which parts can fail separately, which is useful long before anything fails.

What it is not: a capacity plan or a security plan. If you expect a rush of visitors from a launch, read how to handle traffic spikes for the server side. If you shipped quickly with AI tools, the vibe-coded app security checklist covers the holes worth closing first. The status page is how you talk about whatever goes wrong anyway.

What to publish on a status page before an outage#

Components customers recognise#

A component is one part of your service that can fail on its own. Atlassian's component documentation puts it this way: "A good rule to use is to add a component for each major functional/architectural division of your service." When asked which components a company should add, the same page admits: "it depends".

For a small SaaS, think in terms of what a customer does, not what your stack looks like. Customers do not know or care that you use a queue worker. They know whether they can log in, whether the dashboard loads, whether the API answers and whether their emails go out. A typical first list is four to six items:

• Web app (sign in and dashboard)
• API
• Background jobs or scheduled tasks, named for what they do ("Report exports", "Email delivery")
• Payments and billing
• Marketing site and docs, if they are hosted separately
• Third-party dependencies customers would notice, such as your email or payment provider

Keep it short. Free plans cap components: Atlassian Statuspage's free plan includes 25, and Openstatus's free Hobby plan includes one status page "with three components" (both from their pricing pages, checked 18 Oct 2026). More importantly, a page with thirty components is hard to read in a hurry.

A status for each component#

Atlassian's documentation says components "always have one of the 5 following statuses": Operational, Under maintenance, Degraded performance, Partial outage and Major outage. The definitions are worth copying, because they settle arguments in the moment:

• "Degraded performance means the component is working but is slow or otherwise impacted in a minor way."
• A partial outage is when a component is "completely broken for a subset of customers".
• "Components should be set to major outage when they are completely unavailable."

Atlassian's top-level status documentation explains how those roll up into the banner at the top of the page. With two or more components, if any one is in Major outage, the top-level status reads Partial System Outage; only when every component is down does it read Major System Outage. If you build your own page, that is a sensible default to borrow.

Incident states and timestamps#

An incident is the running story of one problem. Atlassian's create an incident guide says "Incidents have one of four distinct statuses": Investigating, Identified, Monitoring and Resolved. Its definitions, in short: Investigating means you see symptoms but do not know the cause; Identified means "you have found the root cause of the incident and are working on a fix"; Monitoring means "you believe you have successfully fixed the issue and are waiting for the symptoms to subside"; Resolved means the cause is gone and systems are back to full performance.

Every update needs a timestamp, and the timezone must be obvious. Hosted tools add these for you. If you build your own, show UTC or the customer's local time, and say which. The same guide gives sample incident names such as "DB connectivity issues" and "API requests timing out": short, specific and free of blame.

Scheduled maintenance notices#

Planned work belongs on the page too, posted in advance. Atlassian lists Scheduled Maintenances in the core feature set on its Statuspage pricing page, and its incident communication templates include a scheduled maintenance format: the service name, the date with start and end time, and what users can expect during the window.

Openstatus's October change shows where this is heading. Its Maintenance updates entry says "A maintenance is now a timeline, like a status report", with follow-ups such as "Work started", "Taking longer than expected" and "Completed early". Each one, the changelog says, "is dated, shows on the public status page, and can notify subscribers." Whatever tool you use, post at the start, if it overruns, and when it ends.

Subscriptions#

Subscribers are why a status page reduces support load rather than adding a tab nobody checks. Email is the baseline. Atlassian adds SMS and webhooks from its Startup plan ($99/month), and its Business plan ($399/month) adds component subscriptions, so customers only hear about the parts they use. Subscriber caps are one of the main differences between plans (see the price table below), so check how many customers you expect to sign up before picking a free tier.

Put the subscribe link where customers will see it before they need it: in your app's footer, your help docs and your onboarding emails.

Incident history and postmortems#

Keep resolved incidents visible. Plans differ on how long they show history, as the AlwaysGreen tiers show (30 days, 90 days, 1 year). For anything that hurt customers, publish a postmortem when you know the cause.

Google's Site Reliability Engineering book defines one as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring." Its list of common triggers starts with "User-visible downtime or degradation beyond a certain threshold" and "Data loss of any kind", and it advises deciding the criteria before an incident happens. It also asks that postmortems be blameless, focused on causes "without indicting any individual or team".

A public postmortem for a small SaaS can be five short paragraphs. A real example of the structure: GitHub's availability report for September 2026, by Jakub Oleksy and dated October 14, 2026, breaks each incident into an impact summary, "What went wrong and why?", "How did we respond?" and a section on making incidents like this less likely. For its September 13 incident it says "A background data-cleanup job increased load on a shared database." That is the tone to aim for: one plain sentence of cause, then what changed.

Host it away from your app#

If your status page shares a server, database, hosting account or DNS setup with your product, one failure can take out both. Then customers see an error where your status page should be, which is worse than having none.

Three rules cover most of it:

1. Its own subdomain. Use status.yourdomain.com rather than a path such as yourdomain.com/status. A subdomain can point somewhere else entirely with one DNS record. Better Stack's pricing page describes the hosted version as "a branded status.yourdomain.com", and AlwaysGreen's page uses the same pattern. If you are still picking a domain, how to choose a domain name for your business covers the basics.
2. A different provider. If your app runs on one cloud, do not run your status page on the same one. A hosted service handles this for you, as long as it is not built on the same provider that just failed you. A self-hosted page needs its own small server somewhere else.
3. A different login. You should be able to post an update from your phone with the app, your laptop and your usual password manager session all unavailable. Store the status page login separately and test it.

The open-source options each carry their own version of this trade-off. The Upptime README says it runs "powered entirely by GitHub Actions, Issues, and Pages", with checks "as often as every 5 minutes", issues "automatically opened and closed" when downtime is detected, and a status page hosted on GitHub Pages. It is MIT licensed with 17.2k stars, and the README says it is "completely free if you're already using GitHub since there's no external server or subscription needed." The catch: your checks then depend on GitHub. GitHub's own September report says its September 13 incident caused intermittent failures for "~4% of actions workflows". If your app also lives on GitHub's infrastructure, this is not separation.

Uptime Kuma describes itself as "an easy-to-use self-hosted monitoring tool." Its README lists multiple status pages, the ability to "Map status pages to specific domains", 20-second intervals and more than 90 notification services. It is MIT licensed with 92.6k stars and runs with a single Docker command. The README warns that file systems like NFS "are NOT supported". Run it on a cheap server with a different provider from your app, not on the same box.

Openstatus is "Available as a managed service or self-hosted", under the AGPL-3.0 licence, with 9.2k stars. That gives you a route to start hosted and move later, or the other way round.

Hosted status page plans and prices compared#

All prices below are as shown on each vendor's own pricing page on 18 Oct 2026 (UptimeRobot re-checked 19 Oct 2026), in the currency the page displayed from this box. UptimeRobot showed euros. Check the live page before you buy.

Some patterns hold across the table:

• Free plans are real but limited. The usual limits are subscribers, components, check frequency and the custom domain. For a product with a few dozen customers, a free tier on a vendor subdomain can be enough.
• The custom domain is the common paywall. Instatus's free Starter plan says "No custom domain"; Statuspage puts it on Hobby. Decide whether status.yourdomain.com is worth the monthly cost now or later.
• Monitoring and status pages are converging. Better Stack, Instatus, Openstatus, UptimeRobot and AlwaysGreen sell checks and pages together. Atlassian Statuspage is a communication tool first; its pricing page lists subscribers, team members and metrics rather than monitors.

For most solo makers, the cheapest sensible setup is a free plan from a tool that also monitors your app, so an alert reaches you before a customer email does. Upgrade when you need the custom domain or outgrow the subscriber cap.

Incident wording: what to say at each stage#

Most of the damage in an outage comes from silence or vague updates. Atlassian's guide says "Silence during downtime costs more trust than the outage itself". Its public template for the first message is short: name the product, say "We are investigating issues with" it, and promise updates. Its partial outage template ends each message with "Next update in" and a time.

Write these before you need them and save them in your status tool's incident templates (Atlassian lists Incident Templates in its core features) or in a note on your phone.

The example wording is ours, not from a vendor or a real incident. A few rules make it work:

• Lead with impact, not cause. Customers want to know what they cannot do.
• Give a next update time and keep it, even if the update is that nothing has changed.
• Avoid "minor" unless it is. If a customer cannot pay you, it is not minor to them.
• No blame, including towards your providers. Say what failed, not whose fault it was.
• Match the component status to the message. If the update says sign-in is broken for everyone, the component should not read Degraded performance.

Pre-outage checklist for a solo maker#

Do this in one sitting, before launch if you can.

1. Pick a tool from the table above, or set up Upptime or Uptime Kuma on infrastructure separate from your app.
2. Point status.yourdomain.com at it, if your plan includes a custom domain.
3. Add four to six components named in customers' words.
4. Write down what Degraded performance, Partial outage and Major outage mean for your product.
5. Save templates for Investigating, Identified, Monitoring, Resolved and Scheduled maintenance.
6. Switch on email subscriptions and add the subscribe link to your app footer, help docs and welcome email.
7. Connect monitoring alerts to your phone.
8. Log in to the status tool from your phone and post a test incident, then delete it.
9. Write your postmortem trigger rule.
10. Link the status page from your support page and your release notes, so customers know where to look.

If you are working through a wider list, the product launch checklist for bootstrapped makers covers the rest of launch week. And if your launch is a Show HN like AlwaysGreen's, how to write a Show HN post is worth reading before you post, since a front-page spike is exactly when you want the status page ready.

Where ZeroRaised fits once your status page is live#

A status page shows a product is run by someone who plans for failure. It does not bring customers on its own.

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. If your SaaS is live, with a status page and a support address customers can reach, you can submit it for review. The maker perks page lists separate offers for eligible makers, and the launch sites directory lists other venues by audience. None of them replaces a clear incident update when something breaks.

So, the SaaS status page checklist: components in customers' words, clear statuses, timestamped incident updates, maintenance notices, subscriptions and visible history, all on a subdomain hosted apart from your app. Set it up now, while nothing is on fire.