Does this client need one?
A status page earns its place when:
- visitors or staff ask “is it down?” in an incident;
- the site is business-critical (shop, booking, member portal);
- the client has an SLA or wants proof of uptime;
- several people at the client need the same information.
It adds little for a five-page brochure site that is rarely down. For those, the monthly report is enough. Offer a status page where it reduces work, not to every client by default.
What a status page should show
- Current state in one word and one colour, with a word as well as the colour. Colour alone fails for colour-blind visitors.
- What the state means: “All systems working”, “Some visitors may see problems”, “The site is unavailable”.
- The incident, if there is one: start time, what is affected, what is being done, when the next update is due.
- Recent history: the last 30 to 90 days of incidents, with the duration and a one-line summary.
- How to get in touch if the problem is not on the page.
Keep it to what visitors need. Internal detail (server names, stack traces, people’s names) stays out.
What to leave out, or handle carefully
- A uptime percentage with no method. If it appears, state the period, the measured URL and how gaps are counted. See Uptime SLA maths.
- Green for “no data”. A day with no valid measurement is unknown. A page that paints it green overstates what you know.
- Individual tests that fail alone. A single failed check from one location is not an incident. If your monitor confirms failures from a second location, publish confirmed incidents only; unconfirmed blips make the page cry wolf.
- Speculation about causes. “Investigating” is honest; “caused by the hosting provider” before you know is not.
- Blame. The page is read by customers, not by lawyers or the hosting company.
Wording incidents
Use a small fixed vocabulary so the page is predictable:
| State | Meaning | Example update |
|---|---|---|
| Investigating | We know there is a problem and are looking | “Some visitors see an error on the checkout page. We are investigating.” |
| Identified | We know the cause | “A payment plugin update caused the error. We are rolling it back.” |
| Monitoring | A fix is in place, we are watching | “The fix is live. We are watching for 30 minutes.” |
| Resolved | The problem is over | “Resolved at 14:42. Checkout was affected from 14:05.” |
Rules for each update:
- start with the impact in visitor terms, then the status;
- give times with a time zone;
- promise a next update time and keep it, even if there is nothing new (“No change; next update 15:30”);
- close every incident with a short resolved note that says how long it lasted.
For planned maintenance, announce it beforehand, state the window and say what visitors will see. The matching HTTP status for a site that is briefly unavailable on purpose is 503 Service Unavailable, which tells browsers and crawlers that the condition is temporary (RFC 9110).
Setting up for a client
- Agree what is shown. One page per client, covering the parts the client’s customers use: the website, perhaps the shop or booking page.
- Choose the audience. Public, or a link shared with the client’s staff only.
- Decide who posts updates and who approves them out of hours.
- Decide how it is brand-labelled. A page under the client’s name looks better; a page under yours is simpler to run. Check what the tool supports. Some tools publish at the vendor’s address only, some on the client’s own domain.
- Link to it from the footer, the 404 page and the support email signature.
- Test it once with a fake incident, privately, so nobody learns the process during a real one.
Mistakes that make it harmful
- Hosting it on the same server as the site. When the site is down, so is the page. Host the status page elsewhere.
- Updating late or never. A page that says “investigating” for six hours is worse than none.
- Letting it go stale. A year-old “resolved” incident at the top suggests nobody is looking.
- Exposing every blip. Visitors lose trust in a page that is always amber.
- Hiding real incidents. A page that shows nothing during a visible outage destroys credibility.
- Promising what you cannot keep. “Fixed in 10 minutes” turns into an hour.
After the incident
Keep the incident on the page for the history. Put it in the monthly report with cause and prevention. If it was caused by a change you made, say so; clients forgive mistakes that are explained and repeated ones that are not.
How Beamfar helps
Beamfar gives each client a public status page. It shows only confirmed incidents (two regions for page checks, the ping receiver for scheduled tasks), so a single failed check never appears, and a day without data is never shown green. On the Agency and Agency Plus plans your own name, logo and accent colour go on the page. The client’s own domain for a status page is built (Team, Agency and Agency Plus plans: a host name you verify with a DNS record, served with a certificate) but not yet tested against real DNS and TLS; otherwise pages are served from Beamfar’s address. Updates for the client are still written by you.
Questions
Does every client need a public status page?
No. It helps businesses where visitors ask whether the site is down, such as shops, booking sites and portals, and clients with an SLA. For small brochure sites the monthly report is usually enough.
What should a status page say during an incident?
The impact in visitor terms, the current state (investigating, identified, monitoring or resolved), the time of the last update and the time of the next one.
Where should the status page be hosted?
Away from the site it reports on, so that it stays reachable when the site is down.
Should a status page show uptime percentages?
Only with the period, the measured URL and how gaps are counted. A percentage with no method, or one that counts missing data as up, cannot be defended.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 9110, HTTP Semantics (503 Service Unavailable) (www.rfc-editor.org)