Do you need a status page for your app or SaaS?

Short answer: A status page is a public place where you tell customers whether your product is working, what's affected when it isn't, and what you're doing about it. You need one once customers depend on your app for their daily work, especially B2B customers who'll otherwise flood your inbox during an outage. Keep it simple: a handful of components, clear incident updates at predictable intervals, and a way for customers to subscribe.

Every app has outages. What customers remember is how they found out and how they were kept informed. A status page turns "is it just me?" into one link, and lets your team fix the problem instead of answering the same email forty times.

What a status page is (and isn't)

A status page is a communication tool, not a monitoring system. Atlassian's documentation for its Statuspage product says so directly: it doesn't monitor your websites or servers itself, but you can connect monitoring tools or update the page through its API. Monitoring tells you something is wrong; the status page tells your customers.

Most status pages share the same building blocks:

Components: the parts of your service customers care about.
Component statuses: Statuspage uses five: Operational, Under maintenance, Degraded performance, Partial outage and Major outage.
Incidents: posts describing a problem, each with a status that moves through Investigating, Identified, Monitoring and Resolved.
Scheduled maintenance: advance notice of planned work.
Subscriptions: ways for customers to get updates without checking the page. Atlassian's docs describe email and SMS notifications (SMS on paid plans), Slack subscriptions and webhooks, and component subscriptions so people only hear about the parts they use.
History: a record of past incidents. Atlassian notes the incident history link appears once a page has been running for 14 days.

Do you need one?

Probably yes if:

Businesses use your product during working hours and an outage stops their work.
You have integrations or an API that other systems depend on.
Larger customers ask about uptime or incident processes during procurement.
Support gets overwhelmed with "is it down?" messages when something breaks.

Probably not yet if:

You have a small number of customers you can email directly.
Your product is used occasionally and a short outage goes unnoticed.

Even then, a basic page costs little effort and is ready the day you need it.

What to show

Components

Atlassian's guidance is to add a component for each major functional or architectural part of your service. For a small SaaS, five to eight components is plenty, for example:

Web app
Mobile app
API
Login and accounts
Payments and billing
Email notifications
Integrations (one per critical integration if they fail independently)

Name them in customers' language, not your server names. "Booking calendar sync" is useful; "worker-queue-2" isn't.

Language

For customers across Germany, Austria and Switzerland, consider whether updates should go out in German as well as English. Write short, plain sentences either way, because people read status updates under stress. Some hosted tools offer page translation; check what yours supports.

Domain

Host the page on its own subdomain, such as status.yourproduct.com, and keep it on separate infrastructure from your app. A status page that goes down with your product is no use.

Hosted vs self-hosted

Hosted services (Atlassian Statuspage and many alternatives) handle hosting, subscriber notifications and uptime of the page itself. You pay a subscription and accept the provider's design limits. Check current plans and prices on each provider's own pricing page.

Self-hosted tools, such as the open-source Uptime Kuma, combine monitoring with status pages; its GitHub page lists multiple status pages, mapping status pages to specific domains and many notification integrations, and it installs with Docker. You control everything but also have to keep it running, patched and separate from your main hosting.

For most small teams, a hosted page is the lower-effort choice. Self-hosting makes sense if you already run your own infrastructure confidently and want monitoring and status in one place.

Incident update templates

Atlassian describes the four incident statuses like this: Investigating (you see symptoms but don't know the cause), Identified (you've found the cause and are working on a fix), Monitoring (you believe it's fixed and are watching), Resolved (the cause is eliminated). Templates for each stage save time when you're under pressure.

Investigating

We're investigating reports that [what customers see, e.g. "some users can't log in"]. [Components affected]. We'll post an update within 30 minutes.

Identified

We've identified the cause: [one plain sentence]. We're working on a fix. [What still works, workarounds if any]. Next update within [time].

Monitoring

A fix has been applied and [feature] is working again for most users. We're monitoring to make sure it stays stable. If you still see problems, [what to do].

Resolved

This incident is resolved. Between [start time] and [end time, with time zone], [what was affected]. [Whether any data was affected or any action is needed]. We'll share what we're changing to prevent this.

Scheduled maintenance

On [date] from [time] to [time] [time zone], [component] will be unavailable while we [reason in one line]. [What users should do beforehand, if anything].

Tips:

Always state the next update time, and keep to it, even if the update is "no change yet".
Use a single time zone consistently (for DACH customers, local time with the zone stated).
Don't speculate about causes before you know them.
After serious incidents, publish a short write-up of what happened and what you changed.

FAQ

Should the status page be linked from my app?

Yes: from the login page, the help centre and error screens. Some tools also offer an embed that shows active incidents inside your app or site.

Should I automate status updates from monitoring?

Partly. Automatic component status changes are useful, but incident wording should come from a person who knows what customers are experiencing.

What if we have no incidents for months?

That's fine. An "All systems operational" page with a clean history builds confidence.

Do customers need to sign up to see the page?

Public pages are open to everyone. Atlassian's docs also describe private pages, viewable only by people who can log in, which suit internal communication.

If you're preparing your app for business customers and want status, monitoring and alerts set up properly, let's talk through your setup.