Monitoring AWS, Azure and DigitalOcean services

“Healthy” in the console vs working in a browser

Each provider's health signal measures its own layer. EC2 status checks confirm the hypervisor is fine and the instance answers at the network level. Azure's VM status says the machine is provisioned and its agent reports in. DigitalOcean's droplet graphs show CPU, memory and disk on the host. These are honest answers — to the question “is the machine we sold you running?” A crashed nginx, an expired certificate, a deleted DNS record or an app returning errors changes none of them. Your users, however, notice all four instantly.

Where the gaps are, layer by layer

• Instance health is hypervisor-level. It verifies reachability of the virtual machine, roughly at TCP level — not that anything on it is serving a website. “2/2 (or 3/3) checks passed” and connection refused coexist happily.
• Load-balancer target health isn't end-to-end. The LB probes one port and path (often a /health endpoint) from inside your network. A health endpoint that returns 200 while the real pages 500 keeps every target “healthy.” And a fully healthy target group says nothing about whether anyone can reach the load balancer itself.
• DNS fails outside the console's view. Route 53, Azure DNS or DigitalOcean DNS will serve whatever records exist — no console warns you that a record points at a load balancer you deleted, or that the domain itself lapsed. DNS failure takes the site off the internet while every infrastructure panel stays green.
• Certificates expire quietly. Managed certs renew themselves only while their validation records stay intact; self-managed certs on instances renew only if that cron still works. Either way, the console isn't watching the certificate your users' browsers actually see.
• The app layer is entirely yours. A bad deploy, a crashed container behind a healthy service, an environment variable gone missing — the cloud reports the infrastructure it manages, and your code isn't part of it.

One outside-in check as ground truth

An external HTTP check against your real URL exercises the whole chain at once — DNS resolution, the connection, the TLS certificate, and the actual response code — from where your users are: outside. It can't be fooled by a passing health endpoint or a green instance, because it doesn't ask any of them; it asks the site. When it fails, the layer it failed at tells you where to look, and everything the console knows becomes useful context instead of false comfort.

This is also the sane answer for teams running on more than one cloud. AWS, Azure and DigitalOcean each define “healthy” differently, in different consoles, with different alarms. An outside-in check is cloud-agnostic by nature — one uniform “does it work for users?” signal across every provider, which is the number you actually put on a dashboard. That continuous outside-in signal is exactly what website monitoring provides.

An honest note on vantage points

One thing to be clear-eyed about, including with us: PingStuff currently checks from a single vantage point, with checks from multiple regions rolling out. A single external vantage can't tell you a site is down only in one corner of the world — but it still catches everything above: dead web servers, expired certificates, DNS failures, error-throwing apps. One honest outside answer beats three green consoles.

Setting it up

Monitor the URL your users use — the domain in front of the load balancer, not an instance IP or an internal endpoint. If separate services live on separate hostnames (an app on one cloud, an API on another), give each its own monitor; each one answers end-to-end for its own chain. PingStuff confirms an outage before alerting and emails you with the failing layer explained in plain English, by email or text to a verified Canadian mobile.