Agent-Based vs External Monitoring: When You Need Both
There are two honest answers to "is the service up?" One comes from outside, walking the same path your users do. The other comes from inside the machine, where the real causes live. Teams that only have one spend outages guessing; teams that have both spend them fixing. This post is about what each kind of monitoring sees, what it's blind to, and how to combine them without drowning in noise.
What external checks see
An external check runs from somewhere on the public internet and tries to use your service the way a customer would: resolve DNS, complete the TLS handshake, pass through the load balancer, hit your application, read the response. If any link in that chain is broken, the check fails — which is exactly what you want, because that's what your users experience.
External checks are the source of truth for availability. They catch expired certificates, broken DNS, regional network failures, bad deploys that return 500s, and the entire class of problems where the process is "fine" but unreachable. What they can't tell you is why. A failed HTTPS check says "customers can't log in." It doesn't say the database host is at 99% memory and the OOM killer just took your connection pooler.
What an agent sees
An agent runs on the host. It reads the things no outside probe can reach: CPU and load, memory and swap, disk space and inode exhaustion, disk and network I/O, file descriptors, process and service liveness, database internals like connection saturation and replication lag, queue depth, certificate expiry from the server's own view, and patterns in log files. These are the leading indicators — the metrics that move before the external check goes red.
That's the whole point of running an agent: most outages have a prologue. The disk doesn't go from healthy to full instantly; it crosses 80%, then 90%, then 98% over days. Replication lag creeps from seconds to minutes. Memory leaks climb one deploy at a time. An agent watching thresholds turns that prologue into a calm, scheduled fix instead of a 2 a.m. page.
The failure modes each one misses
Run only external checks and you're blind to slow-building, host-local problems until they finally tip the service over — at which point you're debugging a hard-down system with no early signal about the cause. Run only an agent and you share fate with the very things you're watching: if the network partitions, DNS expires, or the load balancer misroutes, the host is perfectly healthy and the agent happily reports green while every customer gets a connection error.
Neither view is complete. The gap between them is exactly where the worst outages hide.
External monitoring tells you that you're down. Host monitoring tells you why. You want the answer to both questions before your customers ask the first one.
How to combine them without the noise
More signals can mean more false alarms — unless you're deliberate. A few rules that keep a combined setup trustworthy:
- Make external checks the pager, agent checks the warning. A failed external check on a user-facing endpoint is an incident. A host metric crossing a threshold is usually a heads-up to act on during the day, not a page in the night — until it's severe.
- Set thresholds with headroom. Alert on disk at 85%, not 99%. The entire value of host monitoring is the lead time; thresholds set too high throw that away.
- Require consecutive failures before paging. One bad probe is noise — a route flap or a GC pause. Two or three in a row is signal. This applies to both kinds of check.
- Correlate on one timeline. The magic moment is seeing the external "login failing" alert next to the agent's "db host memory 97%" line, five minutes earlier. That's a diagnosis, not a mystery.
A concrete example
A read-replica's disk starts filling because WAL archiving stalled. With only external checks, everything is green for hours — until the disk fills, Postgres halts, queries fail, and your HTTPS check finally goes red. Now you're reverse-engineering a hard outage under pressure.
With an agent, the disk check crosses 85% at lunchtime and posts a low-severity heads-up. Someone clears the archive backlog that afternoon. The external check never blinks, customers never notice, and the "incident" was a ten-minute task. Same root cause, completely different day.
How Opsentry does it
Opsentry runs both vantage points through one pipeline. External checks probe your HTTP endpoints, TCP ports, DNS, and certificates from outside your infrastructure. The server monitoring agent runs on your hosts and watches CPU, memory, disk, load, databases, queues, logs, and more — configured centrally alongside your external checks. Both feed the same incidents, the same notifications, and the same API, so you get one timeline and one on-call workflow instead of two disconnected tools.
If you're starting from scratch, stand up external checks first for the availability source of truth, then add the agent to the hosts that carry your most important services. For the external side, our guide to uptime monitoring best practices is a good next read.