// guide
Most damaging outages never touch your status code. A field guide to the failure modes uptime monitoring structurally cannot see, and what does catch them.
7 min · conceptual · updated 23 August 2026
Uptime monitoring answers one question well: does this URL respond? For a marketing site that is the whole question. For a product with moving parts it is a weak proxy, and the gap between “the front door responds” and “the product works” is where most expensive outages live.
Here is what fits in that gap.
A background worker dies. Jobs pile up. Nothing errors, because nothing is running — you cannot throw an exception from a process that has stopped.
Every metric on the worker looks perfect. Error rate zero. The web tier is untouched, so every check returns 200. Users notice when the thing that was supposed to happen asynchronously never happens: the email that was not sent, the export that never appeared, the order that was taken but not fulfilled.
What catches it: queue backlog age — the age of the oldest unprocessed message. Not queue depth, which is noisy under normal load, but how long the oldest item has been waiting. Beaam alerts at five minutes.
Your payment provider charges the customer successfully, calls your endpoint, and your endpoint throws. The provider retries a few times and gives up. The charge stands; the fulfilment never runs.
Your homepage is fine. The provider’s dashboard shows a successful payment. The only trace is in your own logs, and in a support email a day later.
What catches it: monitoring the handler as a service in its own right — its error rate if it is a function, its availability if it is an endpoint. Not the site it happens to be deployed alongside.
The primary is healthy. The replica is minutes behind. Reads served from it return stale data — a user updates a setting, reloads, sees the old value, and concludes your product is broken. Which, from where they are standing, it is.
Nothing is down. Every check passes. Latency looks fine, because returning stale data is fast.
What catches it: replication lag as an explicit metric. Beaam treats 120 seconds as broken for MongoDB Atlas, because past that you are serving data users will notice is wrong.
Existing connections keep working. New ones are refused. Whether a given request succeeds depends on pool state at that moment, so the failure is intermittent and maddening — and any single check has a good chance of passing.
What catches it: connections as a percentage of your tier’s limit, alerting before saturation. Absolute counts are useless here because the limit moves with instance size.
Slow, entirely predictable, and still catches people. Postgres does not degrade gracefully at 100% — it goes read-only, and everything that writes falls over at once.
What catches it: disk used percentage with an early threshold. Beaam alerts at 90% and treats it as broken rather than degraded, because the remaining margin is smaller than it sounds.
Nothing is wrong until the exact moment everything is. And the failure is total: browsers refuse the connection outright.
What catches it: expiry as a countdown, not a check for brokenness. By the time a monitor sees the failure, users have been seeing it for however long it took to poll.
None of these are exotic. What they share is that the thing that broke is not the thing being checked. Uptime monitoring samples one surface — the front door — and infers health of everything behind it. That inference holds for a static site and fails for anything with asynchronous work, a database, or a third-party dependency.
Two things close the gap.
Watch the components, not just the surface. Queues, workers, databases and payment providers each need a signal of their own. Their state is not derivable from a status code.
Correlate them. When replica lag causes function errors causes webhook failures, three independent monitors produce three alerts and no explanation. Evaluating them together produces one message naming every affected service and which failed first — the difference between being woken up and being told something useful.
If you are on an uptime tool today, you do not necessarily need to replace it — but do add coverage for the components behind the URL, especially anything asynchronous. The queue is the most commonly missed and among the most damaging.
That is the gap Beaam is built for, and there is an honest comparison against Better Stack and UptimeRobot covering where each one wins.