Why a freelancer or small agency benefits from a public status page for client work
When a client's site goes down, the first message usually comes to you, by phone or in a direct message, and it often arrives before you have looked at anything. A public status page changes that. The client can check the page for themselves, see what you already know, and stop asking the same question while you work.
For a solo developer or a small agency, this matters more than it does for a large product team. There is no support desk to absorb the questions. The person who gets the message is the person doing the fixing. A page that answers 'is it down?' saves time on both sides.
It also shows that someone is watching. Clients rarely mind that a site had a problem. They mind not knowing about it, or hearing about it a day later from their own staff.
What to show: one component per client site or service, with a plain current status
Keep the page to the things a client would ask about. For most client work that means one entry per site, and one per service that matters to the client, such as the checkout, the booking form or the member login. Name each entry the way the client names it. 'Brightwater shop' is more useful to them than 'prod-eu-02'.
Each entry needs a plain current status. Use words a non-technical person can read: operational, degraded, or down. Avoid codes and percentages unless the client has asked for them. If you are not sure what a status means, the client will not be sure either.
Before you set this up, check the docs for how many components the page can show on your plan, and how they are grouped. The page should match what the docs say it does today, not what you hope it will do later. If you can only show one component on your plan, pick the site the client cares about most and add the rest when you can.
What to write when something breaks: what you know, what you are doing, when the next update is due
A good update answers three questions, in this order.
First, what you know. Say what is affected and what is not. 'The contact form on the main site is failing for some visitors. The homepage and the shop are working' is a complete and useful sentence. Do not guess at the cause in public if you have not confirmed it.
Second, what you are doing. 'We are checking the form service and have a rollback ready' tells the reader that someone is working on it. Keep it short and factual.
Third, when the next update is due. This is the line most people leave out, and it is the one that stops the phone ringing. 'Next update by 15:00' gives the client a time to come back to. Then keep to it, even if the update is only 'still investigating'.
For more on the wording itself, see our posts on what to put in an incident update and on downtime messaging. This post is about how a freelancer or agency uses the page, not the template.
Keeping it honest: update the page when you find the problem, not after the fix
The most common mistake is waiting. You notice the problem, you start fixing it, and the page stays green until the fix is in. By then the client has already seen the error, or a colleague has already messaged them.
Change the status as soon as you have confirmed a real problem, even if you do not yet know the cause. A status of 'degraded' with a note saying you are looking into it is more honest, and more useful, than a green tick that is wrong.
The same applies when things recover. Move the status back only when the site is working for users, not when you have deployed a change and hope it has worked. If you are not sure, leave it as it is and check again.
If you find out about a problem from a monitor, write it down in the page the same way you would if a client had reported it. The page should not show a different story to the one your monitoring shows.
Who looks at it: clients, their staff, and you when someone asks 'is it down?'
Three groups use the page, and each needs something slightly different.
Clients want to know whether the problem is theirs to deal with, and when it will be fixed. They do not need the detail.
Their staff want to know whether they should stop taking orders, warn customers or stop an email campaign. Give them the affected component and the next update time, and they can decide what to do.
You use the page too. When someone asks 'is it down?', point them to the page instead of checking and replying from memory. It keeps the answer the same for everyone and gives you a record of what you said and when.
Alert emails from your monitors go only to people in your organisation, so the page is the place where the wider audience hears about a problem. Keep that in mind when you decide what to publish.
How to link it from your support replies and handover notes
A status page is only useful if people can find it. Put the link in three places.
In your support replies. When a client reports a problem, reply with the link and a line saying what you are checking. 'I am looking into this now. You can follow progress at the status page' sets expectations without a long message.
In your handover notes. If someone else takes over a client site, or a colleague covers while you are away, the note should include the status page link and the component names for that site. The next person then knows where the official status is and what to update.
In your client onboarding document. Show the client where the page is and what each status means before the first incident. They will be less anxious when something does break if they already know how to read it.
Keep the scope small: start with the three sites that matter most
It is tempting to add every client site on the first day. Resist it. Start with the three sites that bring in the most money, carry the most risk, or get the most calls. Set up their monitors, check that the status changes when a monitor fails, and run through one update from start to finish.
Once that feels routine, add the next site. A small set of pages that you keep up to date is worth more than a long list that goes stale. Clients notice a status page that has been left at 'operational' for six months, and they notice when it is wrong.
If you run a small agency with a team of up to 10 people, agree who updates each page before you need it. One person should own each site, with a named backup, so that the page does not wait on whoever is in a meeting.
Use the docs to confirm what the status page supports today
This post describes the working practice, not every option in the product. Before you set anything up for a client, check the docs for the current status page features, the number of components your plan includes, and how monitors connect to components. Check the pricing page for what each plan covers, including the free plan's monitor allowance and the Team plan's price for up to 10 people.
If the docs and this post ever disagree, go with the docs. They are kept up to date, and this post is not a feature list.
When you are ready, you can start free at https://app.aperioflow.co.uk/#/signup, set up a status page for your first client site, and add the rest once you have seen how the updates work in practice.