Status Page for a Small SaaS: What to Show and How

A good status page for a small SaaS shows a handful of components named the way customers think ("Dashboard", "API", "Checkout"), each driven by checks that run from outside your servers, so the page turns red without anyone remembering to update it. Add short incident posts in plain words, a daily history bar per component, a feed or webhook so people can follow along, and your own domain. Never publish host names, internal service names, routes or raw error messages.

During an outage, your customers ask one question: "Is it me, or is it them?" A status page answers it without a support ticket. For a small team it also buys time: when the page already says "Checkout is having problems, we are on it", you can fix the problem instead of answering the same e-mail twenty times.

Step 1: Name Components the Way Customers Think

Customers do not know you run api-2, a Redis cache and a queue worker. They know they cannot log in, cannot pay, or cannot see their dashboard. Name components after those things:

Three to six components is plenty. Group them only if you have more than six. Each component should map to something you can actually test from outside.

Step 2: Drive It From Outside Checks

A status page that depends on you updating it by hand will be wrong exactly when it matters, because you are busy fixing the outage. Connect each component to one or more external checks:

• Sign in: the login page returns 200 and contains a known piece of text.
• Dashboard: a health endpoint that touches the database returns 200.
• API: a public, read-only endpoint answers within a few seconds.

Avoid flapping. Mark a component down only after two failed checks in a row; one failure can be a network blip or a cold start. A middle state ("degraded") after one failure is a good compromise. For check design and thresholds, see how to know your website is down.

A simple health endpoint in Express:

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1')
    res.status(200).json({ status: 'ok' })
  } catch {
    res.status(503).json({ status: 'unavailable' })
  }
})

Note the body says nothing about which database failed or why. The check only needs the status code.

Step 3: Write Incident Posts in Public Words

Incident posts are read by worried customers, not engineers. Keep them short and update them on a rhythm:

• Investigating: "Some customers cannot complete checkout. We are looking into it."
• Identified: "We found the cause and are rolling out a fix."
• Monitoring: "A fix is live. We are watching to make sure checkout works for everyone."
• Resolved: "Checkout has worked normally since 14:40 UTC. Sorry for the trouble."

Say what customers experience, which component it affects, and when the next update will come. Do not guess at causes in public, and do not promise times you cannot keep. A fuller write-up belongs in a postmortem; see the postmortem template for startups.

Step 4: Show History With Daily Bars

A row of daily bars per component (green, amber, red) shows at a glance whether today's problem is rare or routine. Compute each component's uptime over the period from the checks themselves, weighted by the number of checks, not as an average of daily percentages. Offering 7, 30 and 90-day views lets customers see both last week and the longer trend. Honest history builds more trust than a page that is always green.

Step 5: Let People Follow Along

Customers and their tools want to be told, not to keep refreshing:

• An Atom or RSS feed of posts works in feed readers and in chat apps that read feeds.
• A webhook lets you trigger your own notifications (e-mail through your own sender, an in-app banner, a Slack message) from component and post changes. Sign each event with an HMAC and a timestamp so the receiver can verify it came from you and reject replays.
• E-mail subscriptions are common on hosted status pages. If you run them yourself, you take on a mailing list, double opt-in and deliverability.

Step 6: Use Your Own Domain

status.yourapp.com looks like part of your product and is easy to remember. Usually you add a CNAME record pointing at your status page provider, and the provider issues the TLS certificate. Keep the status page off your main infrastructure: if your app's servers are down, the page that says so must still load.

Step 7: Know What Never to Publish

A status page is public. Treat every line as something an attacker and a competitor will read:

• No host names, IP addresses, region or cluster names.
• No internal service or queue names, routes or file paths.
• No raw error messages or stack traces.
• No request ids, trace ids or customer identifiers.
• No counts that reveal your size unless you mean to share them.

"Checkout is having problems" is enough. Save the details for the postmortem.

How Relia Keeps a Status Page Current

Relia includes a public status page on every plan. You name the parts (for example "Checkout" or "Dashboard"), optionally in sections, and back each part with your uptime monitors (5 on Free) or, on Growth and Pro, Relia's synthetic checks of your key pages. A part shows degraded after one failed check and down after two. Each part has daily bars with a 7, 30 or 90-day view.

Posts come from two places. You can write and update posts yourself. Relia can also post for you, asking you first by default (or on its own if you switch that on in its autonomy settings), and only for outages visible from outside (a monitor or one of Relia's checks failing), worded in public terms such as "Checkout is unavailable"; it never publishes routes, hosts, counts or ids. There is an Atom feed and a signed webhook (component down, degraded and recovered; post created, updated and resolved; postmortem published) so you can notify your users from your own tools. Relia does not offer e-mail subscribers: it holds no mailing list.

On Free the page is Relia-branded. On Growth ($19 a month) and Pro ($49 a month) you can add your logo and your own domain with a CNAME record; Relia verifies it and serves the page there.

FAQ

Do I need a status page if I only have a few customers?

Once anyone pays you, yes. It answers "is it me or you?" without a support ticket, and a history of honest posts earns trust early.

Should the status page update automatically?

Component states should, from outside checks, so the page is right while you are busy. Incident posts can be automatic for clear outages, but keep the wording public and short, and add human updates as you learn more.

Should I show every internal service?

No. Show what customers use, named the way they would describe it. Internal names confuse customers and tell attackers how your system is built.