{"id":4227,"date":"2026-11-09T18:42:58","date_gmt":"2026-11-09T18:42:58","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/why-external-uptime-monitoring\/"},"modified":"2026-11-09T18:43:07","modified_gmt":"2026-11-09T18:43:07","slug":"why-external-uptime-monitoring","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/why-external-uptime-monitoring\/","title":{"rendered":"Why You Need Uptime Monitoring From Outside Your Server"},"content":{"rendered":"\n

Monitoring that runs on your server can only tell you what the server sees from the inside. It cannot tell you that the server has gone silent, that visitors cannot reach it, or that their browsers are showing a certificate warning. For that you need a check from somewhere else on the internet, the same way your visitors arrive: a separate monitor that loads your site, tests your ports and alerts you when they fail.<\/p>\n\n\n\n

\"Terminal
Checks from outside a server: website status and response time, certificate expiry, and an open and a closed port.<\/figcaption><\/figure>\n\n\n\n

We have run hosting, VPS and dedicated servers for customers since 2013, and the lesson keeps coming back: a server cannot report its own absence. This post explains what internal monitoring misses, then gives a practical checklist for a website, a VPS and a dedicated server.<\/p>\n\n\n\n

Internal and external monitoring are different jobs<\/h2>\n\n\n\n

Internal monitoring<\/strong> runs on the server itself: an agent, a control panel service monitor, a cron script or tools such as Netdata. It is very good at the details: CPU, memory, disk use, which process is slow, whether a service restarted.<\/p>\n\n\n\n

External monitoring<\/strong> runs on a different machine, ideally in a different location. It knows nothing about CPU or processes. It only asks the question your visitors ask: can I reach this site, and does it answer correctly? You need both, because each one is blind where the other can see.<\/p>\n\n\n\n

What internal monitoring cannot see<\/h2>\n\n\n\n

The whole server is down<\/h3>\n\n\n\n

If the server loses power, hangs on a kernel problem or loses its network, the monitoring agent on it stops too. It sends no alert, because it is not running. From your side, silence looks exactly like “all fine”. An external check simply gets no answer and tells you within a minute or two.<\/p>\n\n\n\n

Network and routing problems<\/h3>\n\n\n\n

A server can be healthy and still unreachable: a routing problem upstream, a wrong IP after a migration, a network card that lost its configuration after a reboot. A check from localhost passes every time, because it never leaves the machine.<\/p>\n\n\n\n

DNS mistakes and expired domains<\/h3>\n\n\n\n

Visitors find your site through DNS. If a record is deleted, a nameserver change goes wrong or the domain expires, the server keeps running happily while nobody can find it. An external HTTP check that uses the domain name, plus a DNS record check, catches this. Domain expiry warnings give you time to renew before it happens.<\/p>\n\n\n\n

SSL certificate expiry<\/h3>\n\n\n\n

When a certificate expires or an automatic renewal fails, the web server still answers and internal checks often still pass. Visitors, though, get a full-page browser warning, and many will leave rather than click through it. An external HTTPS check fails on an invalid certificate, and certificate expiry alerts warn you days in advance.<\/p>\n\n\n\n

Firewall mistakes<\/h3>\n\n\n\n

A new firewall rule, a security tool that blocks a range of addresses, or a port change for SSH can lock out visitors or you. Local checks keep passing because traffic from the server to itself is usually allowed. Only a check from outside travels through the firewall the way real traffic does.<\/p>\n\n\n\n

A full disk that breaks the site quietly<\/h3>\n\n\n\n

When the disk fills up, the server stays online, but the database cannot write, sessions fail and the site shows errors or a blank page. Some applications even return an error page with a normal 200 status code. An internal disk alert helps if someone set it up. An external keyword check, which looks for a word that should be on the page, catches the broken page whatever the cause.<\/p>\n\n\n\n

What to monitor: a practical checklist<\/h2>\n\n\n\n

Start small and add checks as you learn what matters. This table is a sensible starting point.<\/p>\n\n\n\n

What you run<\/th>External checks to add<\/th>Suggested interval<\/th><\/tr><\/thead>
Website (shared hosting or any server)<\/td>HTTPS check of the home page; keyword check for a word that only appears when the page works; HTTPS check of the login or checkout page; certificate expiry; domain expiry; DNS record check for the main A record<\/td>1 minute for the home page and checkout, 5 minutes for the rest, expiry checks daily<\/td><\/tr>
VPS<\/td>Everything in the website row, plus ping to the server IP; TCP check of the SSH port; TCP checks of other public services (mail ports 25, 587 and 993, a database only if it is meant to be public); push monitors for backups and cron jobs<\/td>1 minute for ping and web, 5 minutes for mail and SSH, push monitors matched to the job schedule<\/td><\/tr>
Dedicated server<\/td>Everything in the VPS row, plus a check of each public IP if you have several; a check of every important site or service hosted on it; a TCP check of the remote management address only if it is reachable from outside (it usually should not be)<\/td>1 minute for ping and the main services<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Keep the internal side too. On a dedicated server, watch disk health with smartd (see How to Check SMART Status and Monitor Disk Health with smartd<\/a>), because a failing disk gives warnings long before the server goes offline. External checks tell you that something is wrong; internal tools tell you why.<\/p>\n\n\n\n

How often to check, and how to avoid false alarms<\/h2>\n\n\n\n