"Is my website up?" sounds like one question. It's four. DNS can vanish while your server hums along; your app can crash while the box pings fine; a deploy can serve a beautiful HTTP 200 error page. Here's how to watch all four layers at once — so the alert tells you what broke, not just that something did.
When a visitor types your URL, four things have to go right, in order:
Each layer fails independently, for different reasons, owned by different people (registrar, host, your code, your deploy). A downtime tracker that only polls the homepage collapses all four into one red light — and you start debugging the wrong layer at 3 a.m. The fix is cheap: one monitor per layer.
| Monitor | Watches | When it goes red, suspect… |
|---|---|---|
| dns (we resolve a name) | The name resolves — optionally to the IP you expect | Registrar/domain expiry, DNS provider outage, botched migration, hijack |
| ping (we ping a host) | The box is alive on the network | Host down, network/provider outage, firewall change |
| http/s (we poll a URL) | The app answers with a healthy code — and, optionally, the right body | App crash, bad deploy, TLS problem, overloaded backend |
| beacon (it reports to us) | The host from the inside: CPU, memory, disk — and silence if it dies | Disk filling, memory leak, the box quietly dying before the outage |
In the portal, add a monitor per layer for the same site. The http/s one first:
Yes, checks run every minute on the free plan.
Then repeat twice, changing only the type:
The payoff of layers is the pattern. One glance at which monitors are red tells you where to look before you've opened a terminal:
| dns | ping | http/s | Diagnosis |
|---|---|---|---|
| 🟢 | 🟢 | 🔴 | Your app or web server — crash, bad deploy, TLS. SSH in. |
| 🟢 | 🔴 | 🔴 | The host or its network — check your provider's status page first. |
| 🔴 | 🟢 | 🟢* | DNS layer — registrar, DNS provider, or an expiring domain. (*http may stay green for a while on cached lookups — that mismatch IS the clue.) |
| 🟢 | 🟢 | 🟢 but body check red | The sneakiest one: your site is "up" and serving the wrong thing. A deploy shipped an error page with a 200. |
The alert that tells you whose pager should be ringing — yours, or your DNS provider's.
The single most embarrassing outage class: the site "never went down," but every visitor saw an error page — served with a healthy status code. Status-code monitoring cannot catch this by definition. The body check can: give the http/s monitor a string that only appears when the page is genuinely healthy (a footer marker, a JSON field like "status":"ok"), and a 200 with the wrong body pages you like any other outage.
Everything above watches from the outside — which is the point of a downtime tracker (an on-box monitor goes down with the box). But if you host your site on your own server or VPS, one command adds the inside view:
curl -fsSL https://pylonmon.com/beacon.sh | shThat installs pylon-beacon — a tiny open-source agent that reports CPU, memory, and disk into the same dashboard, with the same silence-means-page rule as everything else. Easy choice when you own the host: most "website down" incidents announce themselves as a full disk or a memory leak hours before the outage, and vitals thresholds catch that window.
A full availability stack for one site is three monitors (plus a beacon if you host). The free plan includes 20 monitors with 1-minute checks and alerts to email, Discord, Slack, and webhooks — enough to instrument half a dozen sites in layers without paying anything.
In layers, from outside your own infrastructure: a DNS monitor (does the name resolve), a ping monitor (is the host reachable), and an HTTP/S monitor (does the app answer with the right code — and the right body). The combination of which one fails tells you what actually broke.
Every minute is the practical sweet spot — fast enough that you hear about an outage before more than a handful of visitors do. PylonMon checks every 1 minute on the free plan (30 seconds on paid).
Constantly. DNS failures, expired domains, and error pages served with a 200 status all take your site away from visitors while the server reports perfect health. That's why single-check downtime trackers miss real outages — and why the layered pattern above exists.
Each monitor keeps its up/down history and incident timeline, so you can see every outage, how long it lasted, and which layer caused it — useful for both post-mortems and holding providers to their SLAs.
Monitor your site in layers free → or see uptime monitoring, the cron alerting guide, and the docs.