A status page is a web page that shows whether a company's services are working right now, and what happened when they were not. It lists each part of the product with its current state, carries updates during an incident, and keeps a history of past uptime. Its job is to answer "is it down, or is it just me?" before a customer has to ask.
This guide covers who a status page is for, what belongs on one, how to write incident updates people trust, and how to set one up.
Who a status page is for
- Customers. During an outage they want three answers: is it broken, do you know, and when will it be back. A status page answers all three without a support ticket.
- Your support team. One link replaces a hundred individual replies, and the queue stays usable for the problems that are not the outage.
- Prospects. Buyers comparing tools look at uptime history. A page with real data, including the bad days, is more convincing than a "99.9% uptime" badge.
- Your own team. Sales, success and management get one agreed version of what is happening, so engineers are not interrupted for updates.
- Developers who integrate with you. A machine-readable status feed lets them tell your outage apart from their own bug.
What to put on a status page
| Element | The question it answers | Good practice |
|---|---|---|
| Components | Which part is affected? | Four to eight parts, named the way customers think: Website, Dashboard, API, Checkout |
| Current status | Is it working right now? | One overall banner, plus a state for each component |
| Incident updates | What is going on, and what are you doing about it? | Time-stamped, plain language, newest first |
| Uptime history | How reliable is this service? | About 90 days per component, bad days included |
| Scheduled maintenance | Will planned work affect me? | Start, end and expected impact |
Components
Split the product along the lines customers see, not along your architecture. "Payments" means something to them. "k8s-prod-ingress" does not. If a component can never fail on its own, merge it into another one.
Current status
Use a small, fixed vocabulary: operational, partial outage, major outage, maintenance. The banner at the top should let someone leave after two seconds with the answer.
Uptime history
A row of daily bars per component shows reliability at a glance. Show the figure honestly, and know which one you are showing: uptime counted by checks and uptime counted by duration can differ, as explained in how uptime is calculated.
Scheduled maintenance
Planned work is not an outage, and the page should say so. Mark the component as under maintenance for the window, so nobody reports a problem you caused on purpose.
Public vs private status pages
A public status page can be opened by anyone, with no login. That is the right default for anything customers use: the moment they need the page is often the moment they cannot log in.
A private (internal) status page sits behind a login, single sign-on or a VPN. It suits internal tools and the extra detail that would only confuse customers: queue workers, batch jobs, the third-party services you depend on.
Many teams run both: a short public page in customer language, and a detailed internal one. If you worry that a public page advertises your failures, remember that customers already know when you are down. The page shows that you know too.
How to write a good incident update
Every update should cover four things, in this order:
- What is affected, in customer terms, and what is not.
- What people will notice: errors, slowness, delayed emails.
- What you know and what you are doing. No guesses, no blame.
- When the next update will come. Then keep that promise, even if the update is "no change yet".
A common convention is four stages: Investigating, Identified, Monitoring and Resolved. Post the first one as soon as you know something is wrong. "We are investigating" within five minutes beats a full explanation after forty. Here is a short example:
| Time (UTC) | Stage | Update |
|---|---|---|
| 14:07 | Investigating | We are investigating errors when loading the dashboard. The API and the public website are not affected. Next update by 14:30. |
| 14:26 | Identified | A database failover did not complete cleanly, so about one in three dashboard requests fails. We are moving traffic to the healthy replica. Next update by 14:50. |
| 14:44 | Monitoring | Traffic is on the healthy database and errors have stopped. We are watching for 30 minutes before we close this. |
| 15:15 | Resolved | The dashboard was partly unavailable from 14:02 to 14:41 UTC (39 minutes). No data was lost. We will publish the cause and what we are changing within two working days. |
Compare that with "We are experiencing issues. Our team is working on it." It names nothing, promises nothing, and reads the same at minute five and at hour three.
Common mistakes
- Hosting the page on the systems it reports on. If your servers go down, the page goes with them. Keep it on separate infrastructure.
- Relying on someone to flip the status by hand. At 3 a.m. nobody does, and the page stays green through the outage. Drive component status from monitoring.
- A page that is never red. Customers notice outages. If the page never shows one, they stop believing it.
- Too many components. Forty rows of green hide the one that is red.
- Going quiet. An hour without an update feels like abandonment, even when the team is working flat out.
- Hiding the link. Put it in the site footer, the help centre, the login page and your error pages.
- Deleting history. A resolved incident, shown with its duration, builds more trust than a blank record.
How to set one up
- List what customers depend on. Those are your components.
- Put a monitor on each one. A status page is only as honest as the checks behind it. Use external uptime monitoring, so the page reflects what users experience.
- Create the page and choose which monitors appear on it.
- Agree who communicates. Name the person who writes updates during an incident, and draft templates for the four stages before you need them.
- Link it everywhere customers look when something feels broken.
Status pages in Upmonora
Upmonora's status pages are built on your monitors, so they stay current without anyone touching them:
- Each monitor you select becomes a component, shown under the monitor's name as Operational, Outage or Maintenance. A banner at the top sums up the whole page. One monitor can appear on several pages, which suits a page per client (see uptime monitoring for agencies).
- 90-day uptime bars give every component a daily history and an uptime figure.
- Incidents from the last 14 days are listed automatically with the component, start time and duration. They open when a monitor confirms an outage and resolve when checks pass again. There is no editor for hand-written updates, so send longer explanations through the channels your customers already read.
- Maintenance windows set on a monitor show that component as under maintenance while the window is active, and no incident is opened.
- Each page has a name, a description, your brand colour and an address like
upmonora.com/status/your-company. Custom domains are on the roadmap. A JSON version of each page is available for widgets and integrations.
Pages are public. A "Publicly accessible" switch lets you keep one hidden while you set it up, but there is no password-protected mode. The free plan includes 1 status page, Starter 3 and Business 10, as shown on the pricing page.
For more on running a page well, read our status page best practices. To work out what faster, clearer communication is worth to you, see the real cost of website downtime.
Frequently asked questions
What is a status page?
A status page is a web page that shows whether a company's services are working right now and what happened when they were not. It lists each part of the product with its current state, updates during incidents, and a history of past uptime.
What should a status page include?
Five things: the components customers use, the current status of each, time-stamped incident updates, uptime history (90 days is common) and scheduled maintenance. Use the names customers use, not internal system names.
Should a status page be public or private?
Public for anything customers use, so they can check it without logging in or contacting support. A private page behind a login suits internal tools and more detailed information meant for staff. Many companies run both.
Is a status page the same as uptime monitoring?
No. Monitoring detects problems by checking your service around the clock, while a status page communicates them to customers. They work best connected, so the page changes as soon as a monitor confirms an outage.
