External Website Monitoring: What It Is, How It Differs from Internal Monitoring, and How to Choose a Service

The server answers, CPU is fine, the disk is not full, the logs are quiet — and users see 502 Bad Gateway. Or the site opens for you but not for a customer in another city. Or the certificate expired at 3 a.m. and browsers showed a red “Your connection is not private” page until morning.

All three have one thing in common: from the inside, everything looked fine. External monitoring exists precisely to look at the site from the outside — through the user’s eyes, not the administrator’s.

What external monitoring is

External monitoring (also called uptime monitoring or availability monitoring) is a service with its own points of presence on the internet. From those points it sends a request to your resource at a fixed interval and records the result: response code, response time, and the error if there was one.

What matters is what gets checked. A request from outside travels the whole chain a real user travels:

1. DNS — does the domain resolve, and to the right address;
2. network — do packets reach your server from this region;
3. TLS — is the certificate valid, not expired, with a complete chain;
4. load balancer, proxy, CDN — everything in front of the application;
5. the application itself — did it return the expected code and body.

Any link can break while the server stays “healthy”. That is the core difference from monitoring on the inside.

External and internal monitoring: not “or” but “and”

Internal monitoring — Zabbix, Prometheus + node_exporter, Netdata — runs through an agent on the server. It sees CPU, memory, disk, queues, connection counts. It is irreplaceable when you need to understand why a service is struggling.

But it does not see:

• a DNS problem at the registrar or on the nameservers;
• an expired or incomplete certificate;
• a dead load balancer or CDN in front of the app;
• a blocked or degraded route at one particular ISP;
• the case where “the process is alive, the port is open, but requests get a 502 or an empty page”.

External monitoring sees exactly those — and does not see what the agent sees. So a mature setup looks like this:

If you already run Zabbix, an external service does not replace it — it closes a blind spot. More on combining them: PingZen vs Zabbix, PingZen vs Prometheus Blackbox, PingZen vs Netdata.

What to check

“A ping every five minutes” is not monitoring, it is a formality. Here is the minimum set for a typical site or API.

HTTP/HTTPS. Response code (and not just 200: for redirects and API endpoints the expected code may differ), response time, a keyword in the body — to tell a live page from a hosting placeholder. HTTP checks.

SSL certificate. Not “is it valid now” but “how many days are left”. Let’s Encrypt renews 30 days before expiry, so sensible thresholds are a warning at 14 days and critical at 7; for short-lived certificates (45-day and even 6-day ones exist now) the thresholds must shrink with the lifetime. How PingZen computes thresholds.

DNS. That the domain resolves and the records are the ones you expect. A swapped A record on a hijacked domain looks like “the site works” from outside — it is just not your site. DNS monitoring.

ICMP ping. Packet loss and latency to the host. Useful for servers and network gear, useless for sites behind a CDN. Ping monitoring.

TCP/UDP ports. Databases, mail servers, game or VoIP services — anything that does not speak HTTP. TCP/UDP.

Domain registration expiry. The most embarrassing outage: nobody renewed the domain. A daily WHOIS check closes the question for good. WHOIS.

User flows. A 200 on the homepage does not mean login or checkout work. A transaction check walks a scenario in a real browser — open, sign in, add to cart — and fails if any step breaks. Transactions.

Reverse monitoring (heartbeat). For cron jobs, backups and servers behind NAT that nothing can reach from outside: instead of the service calling you, your job calls the service, and an alarm fires if the signal does not arrive on time. Heartbeat.

From how many locations, and how often

At least two locations. A single checking point is a source of false alarms: any network trouble on its side looks like your site going down. Two or more points let you tell “the site is down” from “the site is unreachable from one region”. The second case is common: geo-blocks, anti-bot filters and routing trouble at individual ISPs produce exactly that picture — the site opens from Moscow and not from Minsk.

If your audience is in a specific country, at least one point should be inside that country. Many services check only from Europe and the US — they show availability for Europeans, not for your users.

PingZen checks from Moscow, Novosibirsk and Minsk, and if you need a region we do not have, you can attach your own checking point on your VM. You choose the aggregation rule yourself: alert on the first failing point, on a majority, or only when all points fail. A separate “partial outage” status shows regional problems without declaring the site down.

Interval: one minute. Five minutes between checks plus failure confirmation means up to 10–15 minutes during which you know nothing. For a shop that is lost orders, for an API lost clients. A one-minute interval on the free tier is one of the first things to compare (see the table below).

How to avoid alert fatigue

Monitoring that wakes you at night for no reason gets switched off within two weeks. What a service needs so that does not happen:

Failure confirmation. One failed request is not an incident. An incident opens after N consecutive failed checks (three by default in PingZen) and closes after a confirmed recovery, not after the first successful response. How incidents work.

Different statuses for different problems. A site answering 429 Too Many Requests is alive — it is rate-limiting your own checks. A certificate expiring in 10 days is a reason for an email, not a 3 a.m. call. Such cases belong in “degraded”, not “down”: the monitor turns yellow, the reason is visible on its card, no incident opens.

Channels and routing. Telegram, Slack, Discord, Microsoft Teams, email, webhooks — and a way to route them: critical to the on-call chat, warnings to email. Reminders while the site stays down, and a cooldown so one incident does not become forty messages. Alert settings.

Choosing an external monitoring service: a checklist

1. Checking points in your region.
2. The interval on the tier you will actually use. “From 30 seconds” in the headline often means “5 minutes on the free plan”.
3. Protocols beyond HTTP. SSL, DNS, TCP, WHOIS, transactions — either the service does it all, or you will run three services.
4. Confirmation and multi-location. Without them you get false alarms.
5. The alert channels you actually use.
6. A public status page — so you do not answer “is something down?” to every customer personally.
7. API and reports. Monthly SLA export and the ability to create monitors from a script, not by hand.

Comparing popular services

Numbers come from our comparison pages as of publication. Pricing changes — verify on the vendor’s site before deciding.

Uptime Kuma is a fine choice if you are ready to run a server for monitoring yourself — and to remember that monitoring living in the same rack as the site goes down together with it. More in the Uptime Kuma comparison.

Setting up external monitoring in five minutes

1. Sign up — via Telegram, Google, Yandex or email.
2. Add the site URL. Check type, interval and confirmation threshold already have sensible defaults.
3. Pick checking points — at least two.
4. Connect the Telegram bot as an alert channel.
5. Add an SSL monitor for the same domain and a WHOIS monitor — the two most common causes of a “sudden” outage.

Step by step with screenshots: quick start.

FAQ

How is external monitoring different from uptime monitoring? Not fundamentally. Uptime is a metric (the share of time the site was available); external monitoring is the way to measure it. In everyday use the terms are interchangeable.

Do I need external monitoring if I already have Zabbix or Prometheus? Yes. They look from the inside and do not see DNS, certificates, load balancers or regional blocks. An external service does not replace them — it closes a blind spot; see the table above.

How often should a site be checked? Once a minute for anything where downtime costs money. Every five minutes for non-critical pages. Less often than a minute makes no sense in 2026: it saves nothing.

The site is behind Cloudflare or an anti-bot filter — will external monitoring lie? It can: the filter serves the checking bot a challenge page with a 200 or 403, and a naive monitor either calls the site healthy or raises a false alarm. A good service recognises the challenge as its own state — we wrote about it in Cloudflare challenge detection.

Can I monitor services inside a private network? Not from outside: an external point cannot reach 192.168.x.x. For that there are private probes that run inside the network and report to the same dashboard.