What is uptime monitoring
Uptime monitoring is a service outside your infrastructure that requests your URL on a fixed interval, records the status code and response time of every answer, and alerts you when a check fails, so you hear about an outage before your users do.
A server cannot report its own death. A crashed process, a VPS that lost its network or a deploy that broke the database connection all look the same from the inside: silence. So something you do not run has to ask from the outside, on a schedule, and tell you when the answer is wrong. That is the whole idea.
How does uptime monitoring work
Each check is one HTTP request and three facts: did the server answer, with which status code, and how long it took. Logdash counts any status from 200 to 399 as up and everything else as down, including no answer within 10 seconds, which it stores as status code 0. When a monitor changes state, an alert goes out, and a second one goes out when it recovers. There is no confirmation round: the first failed check pages you, so a one-check blip costs a down and an up message.
curl -sS -L -o /dev/null -m 10 \
-w '%{http_code} in %{time_total}s\n' \
https://example.com/health
# 200 in 0.084s up
# 503 in 0.091s down, the app answered and said it is broken
# 000 in 10.0s down, nothing answered at allA monitor runs that command on a schedule from somewhere else and turns state changes into messages.
The interval decides how late you find out
- Every 5 minutes: 288 checks a day. An outage can be 5 minutes old before the first failed check, and one shorter than 5 minutes can fall between two checks and never show up. This is the Logdash free plan.
- Every minute: 1,440 checks a day, and you know within a minute. This is Builder.
- Every 15 seconds: 5,760 checks a day. For anything that takes payments. This is Pro.
Website uptime monitoring: what to point it at
For a static marketing site, the homepage is fine. For an app, point the monitor at a health endpoint that runs one cheap database query and returns 503 when it fails. A homepage served from a CDN cache can return 200 for hours while every API request behind it returns 500, and a monitor on that homepage is measuring the CDN, not your product.
What uptime monitoring does not see
It sends one request from one place. It does not see a checkout that takes 9 seconds on a phone abroad or a button that throws a JavaScript error. That is real user monitoring. It cannot see a queue worker either, because a worker has no URL. There the direction flips: the worker calls the monitor after each pass, and silence is the alert. Logdash calls that a push monitor, on Pro, with a fixed 15-second window.
Uptime monitoring tool or a script
Logdash vs curl in your crontab
| Feature | Logdash | curl in cron |
|---|---|---|
| Runs while your server is down | Yes, from outside your network | Only from a second machine |
| Check types | HTTP status and response time | Anything you can script: SSL expiry, ports, DNS |
| Alerts | Telegram and webhook, once per state change | Whatever you wire up, dedupe included |
| History | Checks for 12 hours, hourly stats for 90 days | A log file, if you keep one |
| Cost | Free for 5 services | Free, plus the box it runs on |
When curl in cron is the better pick
- You already run a second server at another provider. A crontab there does not die with your app.
- You need SSL expiry, port, DNS or keyword checks. Logdash has none of them; a script, Uptime Kuma or UptimeRobot does.
- The URL is internal and never reachable from the internet.
- Add the URL Create a service in Logdash and paste the address of your health endpoint, or your homepage if the site is static. The first check runs straight away, so a wrong path shows up in seconds rather than during an incident.
- Pick the interval Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. Each check stores the status code and response time, so the uptime history and latency chart fill in on their own.
- Break it on purpose Connect a Telegram channel, then stop the app or make the endpoint return 503. An alert you never tested is an alert you cannot trust. On the next check the monitor flips to down and a Telegram alert lands on your phone with the monitor name, the status code and the error.