When a website goes down, the biggest cost is often not the downtime itself. It is the dozens of “hey, is something broken?” messages hitting Zalo, the hotline and the fanpage at once, each pulling someone away from actually fixing the problem. A status page exists to answer all of those messages with one link.
What is a status page?
A status page is a public web page, typically on its own domain like status.yourcompany.com, showing the operational state of your service in real time. A typical page has 4 parts:
| Component | Content | Question it answers |
|---|---|---|
| Overall status | One line: all systems operational / incident in progress | “Is it just me?” |
| Component list | Website, API, payments… one status light each | “What is broken, what still works?” |
| Uptime history | 30-90 day chart, uptime percentage per component | “Can this service be trusted?” |
| Incident log | Ongoing and past incidents with timestamped updates | “When will it be fixed, is anyone on it?” |
Every large software company maintains one, and technical users have long developed the reflex of “suspect an outage, look for the status page”. The point worth making: this mechanism is neither expensive nor hard for a small business.
What problems does a status page actually solve?
It offloads support at the worst possible moment. An incident is when your team most needs focus, and also when questions flood in fastest. One link pinned to the fanpage, the email signature and the auto-reply absorbs most of the repeated questions.
It turns downtime into a display of professionalism. Customers understand that every system fails sometimes. What they do not forgive is silence. A status page updated steadily through an incident (“cause identified, restoring now, ETA 30 minutes”) signals that someone is in control, a world away from a dead website with no explanation.
It becomes sales evidence. When a business customer asks “is your service reliable?”, the strongest answer is not a promise but a link to 90 days of public uptime history. Publishing your numbers means you trust your own systems.
It keeps your own team honest. Public uptime numbers create healthy pressure: nobody wants their component glowing red in front of customers.
When does a small business actually need one?
Not everyone needs one on day one. A personal blog or a low-traffic company brochure site can wait. But 4 signs say your moment has arrived:
- Customers ask “is the site down?” more than once a month. The clearest signal: demand already exists, only the page is missing.
- Revenue flows through an online system. An online store, a SaaS, an API for partners: when your customers’ money depends on your uptime, they have a right to see its status.
- You have made a service quality promise, even verbally. Once you have said “our system is stable”, you need public numbers backing the claim.
- More than one person handles incidents. The page doubles as the internal single source of truth: sales checks it and answers customers instead of messaging the developer mid-firefight.
The common thread across all 4: a status page costs far less than what it saves. One hour of 2-3 people answering messages during an incident already exceeds a month of running the page.
There is also a quieter, long-term benefit. Uptime history accumulates into a record you can point to in renewal conversations, partnership negotiations and even hiring. A year of visible, honest numbers says more about how a team operates than any slide. And on the bad weeks, the same public chart forces a useful conversation internally: if the graph shows three incidents this month, the team talks about causes instead of pretending nothing happened.
How do you build a status page properly?
A few rules learned the hard way:
- Separate the infrastructure. The status page must survive the death of your main systems. Put it on a third-party service, or at minimum a different server and domain.
- Name components through the user’s eyes. “Website”, “Partner API”, “Payment gateway”, never “nginx-prod-02”. Easier to understand and nothing leaks.
- Wire it to monitoring, never update by hand. The green and red lights must flip automatically from check results. A hand-updated page is always late, a late page loses trust, and a page without trust has no reason to exist.
- Fewer components, more accuracy. The 3-5 things customers genuinely care about are enough. Do not list 20 internal microservices.
On tooling: you can self-host an open source status page, but remember the paradox above, a page on your own infrastructure dies with that infrastructure. The lighter path is a monitoring service that includes one: AgentWatch runs HTTP, ping and SSL checks from the outside and publishes a public status page on its own URL straight from those check results, while alerting your team over Zalo and email. The Free plan with 10 checks at a 5-minute interval covers a status page for a website plus a few APIs; details on the pricing section.
What can you do this week?
A minimal plan that fits in one sitting: pick the 3 components customers care about most, attach a monitoring check to each, switch on the public status page, then paste the link into your email signature and the fanpage auto-reply. Next time something breaks, instead of answering thirty identical messages, you send one link and get back to the only job that matters: bringing the system back to life.