Automated vs manual status pages: which should you use?
Every status page has to answer one question on every refresh: is this service healthy right now? The difference between tools is who, or what, answers it. There are two models, and the choice shapes how honest and how timely your page can ever be.
The manual model
In a manual status page, a person decides. Someone notices a problem, opens the dashboard, judges whether it is worth communicating, and flips a component to degraded by hand. When it recovers, a person flips it back.
This is how the incumbent tools work by default, and it has real advantages. It is simple, it needs no integration, and a human can apply judgment that a threshold cannot, like knowing a spike is a deploy and not an incident.
It also has a structural weakness. The page is only as fast and as honest as the person watching it. At 3am, mid-deploy, or during the exact incident that has everyone heads-down, the update is late or never happens. The page goes yellow long after the metric did, and green again on a hunch. We pulled this apart in why status pages lie.
Manual fits when your product is small, your audience is forgiving, and an outage is obvious enough that someone will always catch it. It stops fitting the moment your SLA is defined by a number rather than by "is it up".
The automated model
In an automated status page, a measurement decides. Something crosses a threshold and the verdict updates with no one touching it. Within automation there are two very different signals, and conflating them is the most common mistake teams make.
Automation by uptime check
An uptime check pings a URL from outside your network and confirms it responds. It is the easiest automation to set up and it catches hard-down outages well. Tools like UptimeRobot are built around this model.
The limit is what a ping can see. A checkout endpoint can return 200 OK while p99 latency is four seconds and customers are abandoning carts. The check says healthy; the customer experience says otherwise. An external probe tests that a URL responds, not that the metric defining your SLA is inside its threshold.
Automation by internal metric
The other signal is the metric your engineers already watch: request latency, error rate, queue depth, replica lag, certificate expiry. These define healthy in the same terms as your contract. If your SLA promises p99 under 500ms, the page should flip when p99 crosses 500ms, full stop.
The historical reason teams did not do this is that internal metrics live behind your monitoring stack, and putting them on a public page meant exposing that stack or building a bridge. Observer closes that gap: an agent runs inside your network, reads the metric, applies your threshold, and pushes only the verdict outbound. The raw data never leaves.
A quick comparison
| Manual | Uptime check | Internal metric | |
|---|---|---|---|
| Who decides | A person | A ping from outside | The metric you already watch |
| Speed | As fast as the operator | Seconds, but shallow | Seconds, and accurate |
| Sees real SLA | Only if noticed | No, only "does it respond" | Yes |
| Setup effort | Low | Low | Read-only access to your metrics |
So which should you use?
Use manual if you are tiny, your outages are obvious, and you would rather not wire anything up yet. Accept that the page will lag reality.
Use uptime checks if "is it up" genuinely captures your SLA, for example a static site or a simple API where any response means healthy.
Use internal metrics if healthy is defined by a number, which is true for almost every product with a real SLA. This is the only model where the public verdict matches what your engineers see on their own dashboards.
Most mature teams end up wanting the metric-driven model with a human in the loop for publishing: detect automatically, draft the incident, and let on-call approve it in one click. That is the balance covered in the complete guide and in status page best practices.
If you want the page to follow your metrics, start with a free Observer page, or see how it stacks up against the common tools on the compare pages.