Most DevOps teams already have observability. Metrics in Prometheus or Datadog, logs in one place, traces in another, dashboards on a wall. So when an engineer hears "you should also monitor from the outside," the honest reaction is that it sounds like buying a second smoke detector. This post is about why external monitoring isn't a second smoke detector. It's the only detector that sits where the fire is felt, which is on the customer's side of the network.
What internal observability can't see
Every metric your systems emit is a statement about themselves, made from inside. That's fine until the failure is in something the metrics travel through or depend on. A short list of outages that leave dashboards green:
- DNS. A bad record change, an expired zone, a resolver that serves a stale answer to half the internet. Your servers are fine. Nobody can find them.
- TLS. A certificate that renewed on nine origins and not the tenth, a chain that a mobile OS rejects, an expiry that arrives on a weekend. Every request that fails never reaches your application, so it never appears in your logs.
- The CDN or load balancer in front of you. When an edge location misbehaves, your origin sees slightly less traffic and your error rate looks better than usual.
- The observability stack itself. The agent stops shipping, the ingest pipeline backs up, or the dashboard host runs out of disk, and the absence of data reads as calm.
In each case the first alert comes from a customer, a status page tweet, or a support ticket. Black box monitoring exists to get there first. It's an independent client on another network, asking the question a user would ask and refusing to take your word for the answer. If you've read about synthetic monitoring, this is the same idea pointed at infrastructure rather than user journeys.
What "from the outside" means in practice
Outside means three things at once, and teams often get one and skip the other two.
Another network. The check has to originate from infrastructure you don't run, so that your own routing, your own DNS resolvers and your own cloud provider's regional problems can't hide a failure from it.
A user's assertion, not a process's. Status 200 is the weakest possible check. A real external check asserts what a person or an integration would need. The right content on the page, a valid certificate chain with days left on it, DNS answers that match what you published, an API response with the fields and values you expect, a response time inside your SLA. Sentinel's keyword monitoring and server error detection exist because a page that returns 200 with a stack trace in the body is down in every way that matters.
A schedule you don't control. If the check only runs when your cron runs, it shares your cron's failures.
Why one vantage point isn't enough
A single external checker has the same blind spot as a single customer. It can't tell a regional outage from a global one, and it can't tell a real outage from its own bad network day. Multi-region uptime monitoring fixes both by making agreement the signal.
Sentinel checks from Ashburn, Portland, Nuremberg and Singapore, and a monitor is only marked down when regions agree. A CDN edge failing in Europe shows up as Nuremberg disagreeing with the other three, which is a different alert from all four failing, and both are more useful than one checker's opinion. The same consensus rule is what keeps false positives out of your pager: one region's transient packet loss doesn't wake anyone.
Regional visibility also catches the slow kind of failure. A DNS change that propagates unevenly, a certificate that a single origin missed, a route that got worse for one continent. Multi-region monitoring is the difference between "the site is up" and "the site is up for everyone."
Monitoring the monitor
The most underused external check is the one that watches the things that are supposed to run, rather than the things that are supposed to respond.
Cron jobs, queue workers, backups, ETL pipelines and report generators all fail silently by default. Nothing returns a 500 when a nightly job doesn't start. Heartbeat monitoring inverts the check: the job pings a URL when it finishes, and the alert fires when the ping doesn't arrive. It's a dead man's switch for scheduled work, and it's the only way to catch "didn't run" as opposed to "ran and failed." Sentinel's heartbeat monitoring and cron monitoring are built on it.
Serious teams point this at the monitoring itself. Some Sentinel customers have each of our four regions send a heartbeat to their own incident tooling every 30 seconds, so if a region goes quiet for any reason, they get paged by something we don't run. They're monitoring the monitor, and that's the right posture. Any monitoring service that objects to being watched this way is telling you something.
Independence is a requirement, not a feature
An external monitor only earns its name if it keeps working when the things it watches don't, and that has to include the monitor's own control plane.
Sentinel's regions each run their own check schedule from a local manifest, on a local queue, and buffer results locally if the central control plane is unreachable, replaying them afterward with the original timestamps. We prove it by cutting a region off from the control plane on purpose. In the most recent drill, Singapore was firewalled off for sixty seconds, ran every scheduled check on time, buffered the results, and replayed them the moment the link returned. The check history for that minute is an unbroken series. A deploy, a database restart or the loss of the primary costs zero checks in any region.
Ask this of any monitoring vendor, including us. What happens to my checks when your control plane goes down? If the answer involves the word "briefly," the checks stop.
A checklist for your current setup
Run this against what you have today.
- External checks originate from at least three regions on infrastructure you don't operate, and a monitor is only down when regions agree.
- Every check asserts something a user needs beyond a status code, such as content, certificate validity and expiry, DNS answers, API fields and response time.
- Every scheduled job has a heartbeat, and the alert is on the missing ping, not on a failure log.
- The alert path is independent of the thing that failed. If your alerts go through the SMTP server that's down, they're not alerts.
- The monitoring service itself is watched from outside, by you.
- Freshness is a first-class alert. "No result in three intervals" should page, whatever the cause.
How the two views fit together
Internal observability answers why. External monitoring answers whether. You need both, and the mistake is treating the first as a superset of the second. Dashboards will tell you that CPU was fine and error rates were normal during the forty minutes your DNS was broken, and they'll be right, and it won't matter.
Sentinel is the external half. Uptime, SSL, DNS, keyword, API and heartbeat checks from four regions, 30-second intervals on the Business plan, consensus before an alert, and regions that keep running through our own outages. Point your dead-man switch at us. We'd rather be watched.