Customers of a small SaaS rarely open a status page for fun. They open it when something feels wrong, usually while they are already annoyed. So the page has to answer two questions quickly: is it working now, and has it been working lately?
What customers want to see: current state and recent history
Put the current state at the top, in one line. 'All systems operational' or 'Degraded: exports are slow' is enough. Under that, show the last few days or weeks so a customer can see whether this is a one-off or a pattern. A page with a single green tick tells them nothing about the past month, and many will assume you are hiding something.
Keep the wording flat. Do not write 'We are experiencing a minor hiccup' when checkout has been down for forty minutes. Say what is broken and who it affects. A customer who reads 'Checkout is failing for some card payments' can decide in ten seconds whether to wait or to try another route. A customer who reads 'We are aware of a technical issue' cannot.
The page also needs to load quickly and make sense without context. Someone arriving from a support email at eight in the morning should not have to log in or click through three menus to find out whether the problem is on your side.
List components in plain words
Components are the parts of your product a customer can name. Use the words they already use. 'Dashboard', 'API', 'Invoices' and 'Checkout' are better than 'Core services' or 'Infrastructure cluster B'. If a customer cannot tell from the component name whether it affects them, the page has failed at its main job.
Keep the list short. Ten or fewer is usually plenty for a small product. If you have more, group them under a heading a customer would recognise. Each component should map to something you actually watch. When a check fails, the matching line should change. If a component is not tied to a monitor, someone has to remember to update it by hand, and that is when the page starts to drift from reality.
It helps to write a one-line description for each component as well. 'API: requests from your integrations and mobile clients' tells a developer customer what to look at without a support ticket.
Post updates even when there is little to say
The hardest habit is posting when nothing dramatic has happened. A short update does more for trust than silence, though. 'We are seeing elevated error rates on the API. We are looking into it. Next update in 30 minutes.' Then the next one, even if it is only 'Still looking. No change yet.'
Silence during an incident is what sends customers to your support inbox. A regular rhythm tells them someone is on it and that the page is current. You do not need to reveal internal detail to do this. You only need to show that the thing is being handled.
When the problem is fixed, post a closing line that says what was affected, for how long, and that it is resolved. Do not let the incident quietly vanish from the top of the page. Customers want to know it is over, and they want to hear it from you rather than work it out from the page changing.
Keep old incidents visible
Resist the urge to tidy the history. Deleting a bad week makes the page look better for a day and worse for much longer, because customers remember the outage and notice the gap. Leave resolved incidents in place with their timeline, including the ones that were embarrassing. A history that includes problems is more believable than one that never has any.
Honesty also means adding a short note afterwards when you know more. 'Cause: a certificate expired during the renewal job. Fix: renewal now runs 14 days before expiry, and a heartbeat check confirms it ran.' That is more useful than a vague postmortem, and it shows the team learned something concrete. Keep it to a few sentences. Nobody reads a long report on a status page.
Who owns the page in a small team
On a team of three or four, the page often belongs to nobody. The developer who fixes the problem is busy fixing it, so the update never gets posted, and the page stays green for an hour while customers are complaining. Name one owner for updates and one backup. The owner does not need to write every word, but they need to be the person who notices when the page is stale.
Agree on two rules. First, whoever gets the alert posts the first update within a set time, even if it is only 'We know, looking.' Second, whoever closes the incident writes the closing line. Put these rules in a short shared note so new people know them without being told. A rule written down once is much easier to follow than a habit everyone assumes someone else has.
Alert emails go only to people in your organisation, so the person on call and the page owner see the same warning at the same time. The alert is for the team. The status page is for customers. Keeping those two roles separate makes it clearer who does what when something breaks.
Where to start
You can set up a useful page in an afternoon. Pick your components, connect the checks you already run, and write one update you would be happy to post the next time something breaks. Then leave the page in place so that the history builds up over time.
AperioFlow lets you run monitors, catch errors and publish a status page from one place, and the free plan includes 10 monitors. If you have a team of up to 10 people, the Team plan is 29 pounds a month flat, as shown on the pricing page. Create your status page on AperioFlow at https://app.aperioflow.co.uk/#/signup, and start with the components your customers ask about most.
Hosted in France. Run from the UK. You can download your data.