When something breaks, some of your customers will check your status page before they write to you. Others will never look at it. A small team needs the page to answer the first question quickly, so the next question is easier to handle.
Why customers check a status page before they email you
A customer who cannot log in wants to know one thing: is it them, or is it you? If they can see a clear status page with a current entry, they know you are aware of the problem. That saves them a message, and it saves you the time spent replying to the same question forty times.
A status page does not need to be long. It needs to be accurate and easy to find. If the page says everything is operational while the login is failing, customers will stop trusting it, and they will email you anyway.
What a small SaaS should put on a status page: components, current state, recent incidents
Keep the page to three things.
First, components. These are the parts of your product that a customer would recognise by name: the web app, the API, the login, the email sending, the public site. Do not list every server. Customers do not think in servers.
Second, current state. Each component should show whether it is operational, degraded or down. Use the same words every time so that a customer can read the page at a glance.
Third, recent incidents. Show the last few problems, with the time they started, whether they are resolved, and a short note on what happened. This is the record customers look at when they want to know whether a problem is a pattern.
You do not need graphs, long histories or a large amount of text. A page with three components and a short incident list is enough for most solo developers and small teams.
Wording a first notice: what you know, what you don't, when the next update will come
The first notice is the hardest to write, because you are working with incomplete information. Write it in three parts.
State what you know. For example: "The login page is returning errors for some users." Name the component and the symptom. Avoid guessing at the cause in the first notice.
State what you don't know yet. For example: "We have not yet found the cause." This is honest, and it stops customers from asking whether you are looking into it.
State when the next update will come. For example: "We will post an update within the next hour." Then keep that promise, even if the update is only "still investigating". A customer who is told when to expect news will wait calmly. A customer who hears nothing will assume the worst.
For more on the wording of later updates, see our post on what to put in an incident update. This post is about running the page, not writing each message.
Keeping it current: who posts, how often, and when to mark it resolved
A status page goes wrong when nobody owns it. Decide before the next incident who posts. In a team of two or three, this is usually whoever is on call. Write that name down somewhere the team can find it.
Decide how often you will update. A common pattern is an update every 30 to 60 minutes while an incident is open, even if the update says nothing has changed. Silence is what makes customers write in.
Mark the incident resolved only when the component is working for customers, not when you have deployed a fix. Check the login yourself, from a browser that is not logged in. Then post a short resolution note that says what was affected and what you did. Leave the incident in the recent list so the record is complete.
Posting scheduled maintenance with a short example notice
Scheduled maintenance is different from an incident, because you choose the time. Post it at least a day ahead, so that customers who plan their work around your product have time to adjust. Give the start time, the expected end time, and which components will be affected.
An example notice:
Scheduled maintenance: database upgrade Affected: web app and API Starts: 22:00 on the Thursday, with work expected to finish by 23:00 You may see short periods of errors during this window. We will update this page when the work is complete.
That is the whole notice. Keep it short, and avoid promising that nothing will go wrong.
Linking the status page from your app, your support address and your alert emails
A status page only helps if customers can find it when they need it. Put a link to it in three places: inside your app, in the footer or help menu; on your support page or the auto-reply to support emails; and in the alert emails that your own team receives during an incident, so that anyone copying a message to a customer can include it.
Alert emails from AperioFlow go only to people in your organisation. They are for your team, not for your customers. Use them to get the right person to the page quickly, then let the page do the talking for everyone else.
Connecting monitors to the status page so the page reflects what your checks see
The fastest way to keep the page honest is to connect it to the things you already watch. A monitor that checks your login page, your API or your public site can tell you when something stops responding. When the check fails, you see the alert. You then decide whether the failure is worth a public incident, and you post it.
Heartbeat monitors work differently. They expect a regular signal from a cron job or a backup, and they alert you when the signal stops. A nightly backup that has not reported in is a problem your customers may not see yet, but you need to know about it before they do. Catching that early is often the difference between a short notice and a long apology.
Start with a few monitors on the things your customers use most. On AperioFlow's free plan you can set up to 10 monitors, so you can cover the login, the main page, the API and a few scheduled jobs without paying anything. You can also download your data at any time if you decide to move on.
If you want to try the whole flow, set up one monitor and one status page, then post a test incident and resolve it. It takes a few minutes, and it shows you what your customers will see before you need it. Start free at https://app.aperioflow.co.uk/#/signup.
AperioFlow is hosted in France and run from the UK.