Status pages: what to put on one and how to write updates

A status page is a web page that says whether your service is working right now, and what you are doing about it when it is not. Its job is to answer "is it you or is it me?" in ten seconds, without the customer having to contact you.

Three groups read it, and each wants something different.

A fourth reader is easy to forget: a buyer deciding whether to trust you. They look at your incident history before they sign, and clear, honest updates count in your favour.

Six things belong on it: components with their current state, incident updates, incident history, uptime history, a way to subscribe and scheduled maintenance. Internal detail, blame and guesses do not.

• Components and current state. One state per component.
• Active incidents. A title, the affected components and a list of timestamped updates, newest first.
• Incident history. Past incidents with every update left as it was written.
• Uptime history. A percentage for each component over a fixed period, for example the last 90 days.
• A subscribe option. So people hear about incidents without checking the page.
• Scheduled maintenance. Planned work, with dates and times, before it happens.

Decide how you count uptime and say so on the page. Does a partial outage count as downtime? A worked example: a 30-day month has 43,200 minutes. If a component was down for 49 of them, its uptime is (43,200 - 49) / 43,200 = 99.89%. The uptime calculator does this in both directions.

What does not belong

Split it by what a customer does, not by how you built it. A component is one thing a customer would say is "down": "I cannot log in", "the API is failing", "emails are not arriving".

1. Use the customer's words. "Web app", not "frontend cluster".
2. Keep it short. Four to eight components suits a small product.
3. Each one can fail on its own. If two always go down together, they are one component.
4. Each one maps to something you check. If you cannot tell whether it works, you cannot report on it.
5. Hide your internals. Databases, caches and queues are not components.

Example: a small SaaS product

Acme Invoices is a made-up invoicing app. Its customers create invoices in a web app or through an API. Their own clients receive those invoices by email and pay them online. Five components cover everything a customer can notice:

Notice what is missing: "PostgreSQL primary", "Redis", "worker-3". A customer cannot act on those. If the database fails, Web app and API both turn red, and that tells the customer what they need to know.

The same goes for suppliers. The card processor sits inside "Online payments", with no need to name it.

Use five: operational, degraded performance, partial outage, major outage and under maintenance.

Write your thresholds down

The person on call at 03:00 should not have to judge whether this is "degraded" or "partial". Give them numbers. These are an example, not a standard:

• Degraded performance: 1% to 5% of requests fail, or the slowest 5% take longer than 3 seconds, for 5 minutes.
• Partial outage: 5% to 50% of requests fail, or one named feature does not work.
• Major outage: more than 50% of requests fail, or nobody can log in.

Two rules for choosing

• When torn between two states, pick the worse one. A page that says "operational" while customers see errors costs you more trust than one that says "degraded" for an hour too long.
• Never use "under maintenance" for unplanned work. If you did not announce it beforehand, it is an incident.

Host it somewhere that stays up when your product goes down. If the page runs on the same servers, the same cloud account or the same DNS as the product, it fails at the exact moment people need it.

Ask of each item below: does the status page share it with the product?

• Servers. The page must not be a route inside your own app.
• Cloud provider, account and region. A regional outage or a suspended account takes both down.
• DNS. If the DNS for example.com fails, status.example.com fails with it.
• Login. Customers should read the page without logging in. Staff must be able to edit it when your company login is broken.

For the hosted route, PULSX is one option that costs nothing: its status pages are free and public, with subscribers, themes and announcements.

status.example.com is the address people guess, so use it. It does share your DNS zone. To cover that, keep the provider's own direct address for your page in your support replies and bookmarked by everyone who may need to post.

Once a quarter, ask: if our main hosting provider vanished right now, would the status page load, and could we log in and post?

There are four: investigating, identified, monitoring and resolved. Each tells the reader how far along you are.

A short incident can go from investigating straight to resolved. You can also go backwards: if the fix does not hold, return to identified and say so.

A worked example: four updates for one incident

Acme Invoices again. On Thursday 8 October 2026, a configuration change at 08:58 UTC made about 1 in 3 logins to the web app fail. An alert fired at 09:06. The team set the Web app component to "Partial outage". The incident title says what users see, not what broke: Some customers cannot log in.

INVESTIGATING (8 Oct 2026, 09:12 UTC)

Some customers are seeing an error page when they try to log in to the
web app. We are investigating.

If you are already logged in, you can keep working as normal. The API
and invoice emails are not affected.

Next update by 09:40 UTC.

This went out 6 minutes after the alert. It does not guess the cause.

IDENTIFIED (8 Oct 2026, 09:34 UTC)

We have found the cause. A change we made to our login service at
08:58 UTC is making about 1 in 3 login attempts fail.

We are reversing that change now. If your login fails, trying again may
work.

Next update by 10:00 UTC.

It gives the cause in one plain sentence and a workaround. It gives no fix time, because nobody knew one.

MONITORING (8 Oct 2026, 09:51 UTC)

We reversed the change at 09:47 UTC and logins are working again.

We are watching closely for the next 30 minutes. If you still cannot
log in, reload the page and try once more. If that fails, contact
[email protected].

Next update by 10:25 UTC.

RESOLVED (8 Oct 2026, 10:21 UTC)

This incident is resolved.

Between 08:58 and 09:47 UTC, about 1 in 3 attempts to log in to the web
app failed. The cause was a configuration change to our login service,
which we have reversed. No data was lost. The API, invoice emails and
online payments worked throughout.

We are sorry for the disruption. We will post a full write-up on this
page within 5 working days.

The last update stands on its own: what happened, for how long (49 minutes), why, and whether data is safe. The promised write-up is a postmortem, and the postmortem guide shows how to write one.

Say what users see, who is affected, what you are doing and the clock time of the next update. Use words a new support agent would understand on their first day. Post on a fixed rhythm, even when nothing has changed.

1. Say what users see, not what broke inside. "Logins are failing" comes before any mention of the cause.
2. Say who is not affected. "The API is not affected" stops half your customers worrying.
3. Give the next update as a clock time. "By 09:40 UTC", not "soon" and not "in 30 minutes", which depends on when the reader sees it.
4. No jargon. No "failover", "pod" or "5xx".
5. Never guess a fix time you cannot keep. If the work has a known length, such as a restore that takes about two hours, give a range and call it an estimate.
6. Do not guess the cause. "We do not know yet" is an acceptable sentence.
7. Apologise once, in the resolved update.
8. Do not edit or delete earlier updates. Post a correction as a new update.

Bad update, better update

How often to post

Post at once whenever the stage changes. Between changes, this is a sensible default:

• Major outage: at least every 30 minutes.
• Partial outage or degraded performance: at least every 60 minutes.
• A long incident that runs overnight: every 2 to 4 hours, if you say so in the update.

An update that says "nothing has changed" is still worth posting. Silence is when customers start writing to support.

Post a notice on the status page in advance and send it to subscribers. It must give the date, the start and end times in UTC, the components affected, what customers will notice and what they need to do.

These are a starting point. If you have contracts with an uptime promise, read them first. They may set a minimum notice period. The guide to uptime SLAs explains those clauses.

An example notice

SCHEDULED MAINTENANCE: database upgrade
Sunday 18 October 2026, 02:00 to 03:00 UTC
Posted: Sunday 11 October 2026

We are upgrading the database behind Acme Invoices.

What you will notice
- The web app and the API will be unavailable for up to 15 minutes at
  some point inside this window.
- Invoice emails due during that time will be held and sent as soon as
  the work is finished.

What you need to do
- Nothing, if you use the web app.
- If you use the API, make sure your software retries a failed request
  after a short wait.

We will post here when the work starts and again when it is finished.
Questions: [email protected]

During and after the work

• Send subscribers a reminder 24 hours before the start.
• At the start, set the affected components to "Under maintenance" and post that work has begun.
• At the end, post what was done and how long the downtime really was: "The upgrade is complete. The web app and API were unavailable for 11 minutes."
• If the work will run past the announced end, say so before that time arrives. If it goes wrong, open an incident.

Let people subscribe, so they hear about incidents and maintenance without checking the page. Email is the baseline. Many status pages also offer a feed or a webhook, so customers can send updates to their own chat tool.

• Confirm each subscription. Send an email with a link the person must click before they are added. This stops anyone signing up an address that is not theirs.
• Put an unsubscribe link in every message.
• Send from the status page, not from your product. If your own email system is the thing that is down, a notice sent through it will not arrive.
• Use the list for service notices only. Send a product newsletter and people will leave.
• Subscribe your own staff. Add the support inbox and your company chat channel, so staff never hear after customers do.

What to send

Too many messages train people to ignore them. An incident that lasts an hour should produce about four emails, one per stage.

Start the subject line with the stage, then the title: "Identified: Some customers cannot log in". Put the full text of the update in the body. Do not make people click to find out what is wrong.

Use both. Let monitoring change the state of a component, and have a person write the words. Each approach on its own has a clear risk.

Why retries matter

A single failed check proves very little. The request may have been dropped somewhere between the monitor and your server.

A worked example: a check runs every 60 seconds. When it fails, the monitor retries 3 times, 30 seconds apart. A real outage is confirmed about 90 seconds after the first failure, and a single dropped request never reaches the page. The retry figures are the defaults PULSX uses before it sends an alert.

Making the manual half fast

• Give at least three people permission to post, including one outside engineering.
• Keep a ready-made "investigating" update with gaps for the component and the next update time.
• Agree one rule: when in doubt, post. You can close a false alarm with "We saw errors for 4 minutes from 09:06 UTC. They have stopped."

You need one when the audience is limited: your own staff, or a single customer with their own environment. A private status page shows the same kind of information as a public one, but only to people who are allowed to see it.

• Internal tools. The VPN, the build system, the staging environment. Staff need to know when these are down. Customers do not.
• A more detailed view for staff. The public page lists 5 components. The internal one lists 25, with real service names and links to dashboards.
• One customer's dedicated environment. Their page covers only their systems.

Access is limited by a company login, a shared password or a network rule (office or VPN addresses only). Each has the same trap: never put the page that reports on a system behind that same system. If the VPN is down, a page that needs the VPN cannot tell anyone.

Two rules apply. The internal page can say more than the public one, never something different. And it is still no place for passwords, keys or customer data, because a private page can leak.

A small team does not need one. If everyone is in the same chat channel, that channel is your internal status page.

Check four things: the page is separate from your product, the components are tied to real checks, people know how to post, and customers can find it.

Setup

1. The page is hosted on different infrastructure from the product.
2. It loads without logging in.
3. It is at status.yourdomain.com, and you have noted the provider's direct address as a fallback.
4. It has four to eight components, each named in words a customer would use.
5. Every component is tied to at least one check on something customers do.
6. Checks retry before they change a state.

People and process

1. At least three people can post, and one of them is outside engineering.
2. Your thresholds for degraded, partial and major are written down.
3. You have ready-made wording for "investigating" and for a maintenance notice.
4. "Post to the status page" is a named step in your incident checklist.
5. You have run one practice incident from investigating to resolved, and the notification emails arrived.

Making it findable

1. Your app's footer, help centre, login page and error pages link to it.
2. The subscribe button, the confirmation email and the unsubscribe link all work.

After each incident, ask one question: did a customer who read only this page know what was happening?

If you do not have a status page yet, you can set one up on PULSX with a free account. No card is needed.