"The site is up" and "I can use the service" are different claims, and a check of the front door only ever proves the first. Most user-visible outages at large services are not the website falling over. They are one component behind it.
Three systems wearing one name ¶
What you think of as a single service is usually at least three deployments with separate failure modes:
- The marketing and content site. Static, CDN-cached, almost never down. This is what a naive uptime check measures.
- The authentication system. Often a separate identity provider, sometimes a third party. When it fails, the site loads perfectly and nobody can get in.
- The application API. What the web app and the mobile app both talk to after login. Dynamic, stateful, database-backed, and by far the most likely to break.
A green check against the homepage tells you the first of the three is fine. It says nothing about the other two, which is where users actually live.
How to tell which one it is ¶
| What you see | Most likely |
|---|---|
| Homepage loads, login page loads, credentials rejected or hang | Authentication |
| Logged in already, but actions fail or data will not load | API |
| Web works, mobile app does not | App API version or app release |
| Mobile app works, web does not | Front-end deploy or CDN |
| Nothing loads at all, including the marketing pages | Genuine site outage, usually brief |
Authentication outages ¶
The most disruptive and the least visible. Single sign-on providers are shared infrastructure, so one identity provider failing takes out dozens of unrelated products at once and none of their status pages will mention each other. If your whole toolchain logs you out simultaneously, suspect identity before you suspect coincidence. SSO outages covers the pattern.
The signature: the login page renders, submitting hangs or returns a generic error, and an already-open session in another tab keeps working until its token expires.
API outages ¶
The page loads its shell, then spinners never resolve, or you get an error banner over a perfectly rendered layout. Open your browser developer tools, Network tab, and reload: a wall of 5xx or timed-out XHR requests against an api. hostname is your answer. That hostname is usually checkable on its own, and it is what you should point a monitor at rather than the homepage. Why a site can load while its API is broken goes deeper.
Mobile app outages ¶
Apps pin to specific API versions, ship their own bugs, and cache aggressively. When web works and the app does not, the split is usually one of three things: a bad app release, a server-side change the installed version cannot handle, or the app being unable to refresh its authentication token. Reinstalling helps only in the last case, which is why it sometimes works and sometimes does nothing.
Checking the right thing ¶
If you monitor a service you depend on, point the check at the endpoint that matters rather than the front door. Our checker takes any hostname, so an API host can be checked directly, and a keyword assertion on a page that only renders when a backend responds catches the failure the front door hides.
That is the whole lesson: a check is only as honest as the thing it checks. Measuring the easiest endpoint and reporting it as service health is how a monitoring tool ends up saying everything is fine during an outage.
Why the status page will not settle it ¶
Status pages are updated by people, usually after an incident is confirmed, and they describe components the vendor chose to name. Three consequences follow, and all three are routine rather than exceptional:
- They lag. Fifteen to sixty minutes between users noticing and the page changing is normal.
- They under-report partial failures, because a component that is 5% broken does not fit a green-amber-red model and the honest label is contentious internally.
- Their component names rarely match what you experience. "API" may cover a dozen services, only one of which is failing.
Read them, but read them as one input. Independent measurement, your own developer tools, and reports from other users are the other three.
Checking each layer directly ¶
You can test all three systems from a terminal in under a minute, and the results are unambiguous in a way that a screenshot is not.
- The site:
curl -sS -o /dev/null -w "%{http_code} " https://example.com - The API: the same command against the API hostname, which is usually visible in the Network tab of your browser tools. A different result from the site is the whole answer.
- Authentication: hardest to test from outside, because it needs credentials. The proxy signal is whether the login page itself renders and whether an existing session in another tab still works. A session that survives while new logins fail points squarely at the token-issuing path rather than the whole identity system.
If you depend on it, monitor the right layer ¶
The practical lesson for anyone running a monitor: point it at the endpoint whose failure would actually hurt you. A check against a marketing homepage is a check of a CDN cache. If your business stops when the API stops, the API is what needs watching, and a keyword assertion against a page that only renders correctly when the backend answers catches the class of failure a status code never will.