What is uptime monitoring and why can a website be down even if the server is still on?
Published on 2026-10-21 by frfrand
Availability monitoring: HTTP checks, latency, alerts, regions, and false positives explained.
Uptime monitoring consists of periodically checking whether a service responds as it should. It is useful because a machine can remain on while its website is down, returns errors, or takes so long that no one can use it.
Monitoring only whether the server responds to a ping is not enough to verify that visitors can make a purchase or log in.
The example of a restaurant
A restaurant can have the lights on, the cooks present, and the door open. But if the cash register does not accept payments, an important part of the service is failing.
Something similar happens on a website. The operating system may be running, Nginx may respond, and yet a database query may fail on every request.
That is why it is advisable to measure the availability of the service that the customer actually uses, not just the existence of the machine.
What can an uptime monitoring tool check?
A basic check performs an HTTP request and observes whether there is a response within a time limit. It can review the returned code, the time it took, and, depending on the tool, whether expected content appears.
For example, the home page could respond 200 OK, but contain a maintenance message. A monitor that only checks the code may consider it healthy. A monitor with specific validation could detect that behavior.
It is also not advisable to use an overly complex route for all checks: a costly operation repeated constantly could add unnecessary load.
What is a health check?
It is a check designed to report the status of a component or application.
There may be a route such as /health that indicates whether the service is ready. In distributed systems, liveness and readiness checks are sometimes distinguished: one asks whether the process needs intervention; the other whether it is ready to handle traffic.
They are not exactly the same. Restarting an application every time an external database takes a few seconds can worsen an outage.
Why is it advisable to monitor from multiple locations?
A page may work from your office and fail for visitors from another country due to DNS issues, regional connectivity, or the provider's network.
Checking from different locations helps distinguish a general outage from a localized problem. But it can also produce false alarms when a single monitor has its own issues.
A sensible policy may require more than one failed check before alerting.
How is the availability percentage calculated?
If a service operates during almost the entire period, the percentage may be high, but the meaning depends on how you define the observed time and what you consider an outage.
A figure like 99.9% may seem close to 100%, but it has real operational implications. Moreover, it does not by itself describe whether pages took one second or twenty.
That is why it is advisable to complement availability with latency and error rate.
What should an alert do?
Warn when there is a situation that someone can act upon. It should include which service fails, since when, and where the problems were observed.
If the system sends fifty notifications during the same incident, it can hinder the response. Grouping events and documenting procedures is more useful than increasing the number of messages.
What errors appear when configuring monitors?
Checking only ping: the machine may be on, but the web server may not be working.
Using an impossible interval to maintain: overly frequent checks generate cost and traffic.
Not testing alerts: you may think you will receive a warning and discover too late that it was misconfigured.
Confusing absence of measurements with success: if the monitor stopped working, that does not prove the website is still available.
How would it be applied in ArduMaker?
If you host a website on an ArduMaker VPS, an external monitor can periodically check the public domain and alert when it stops responding. This complements internal server monitoring and helps distinguish an infrastructure problem from one visible to visitors.
In short: uptime is not just about a server being turned on. It is observing, from the outside, whether the service meets a useful condition and alerting when it stops doing so.
Sources: Google SRE: Monitoring Distributed Systems · Google Cloud: Uptime checks.