---
title: "VPS monitoring: free uptime checks and alerts | Logdash"
description: "An outside HTTP check on the free plan, a heartbeat script that goes quiet when the disk fills or the app dies, and Telegram alerts in 3 steps."
url: https://logdash.io/monitor/vps
---

# VPS monitoring

VPS monitoring means an outside check that alerts you when the server stops answering, plus a heartbeat from inside that stops when the disk fills or the app dies, because most provider dashboards give you graphs rather than alerts.

Start with what the provider already gives you. Hetzner Cloud shows CPU, network and disk IO graphs in its console and sends no alerts. DigitalOcean has a free metrics agent with threshold alerts, and uptime checks at $1 a month each after the first. Most others sit between the two. A resource graph cannot tell you that nginx answers 502 to every visitor, because the box itself looks idle.

Two failures matter on a single VPS. The fast one: the server or the app stops answering from outside, after a kernel panic, the OOM killer, a bad deploy or a provider network fault. The slow one: logs fill the disk until Postgres refuses writes. The first needs a check from somewhere else. The second needs something on the box.

## VPS uptime monitoring from outside

Put an HTTP monitor on a public URL of your app, ideally a health route that runs one database query. The Logdash free plan covers five services checked every 5 minutes, Builder checks every minute for $9 a month, Pro every 15 seconds for $15\. Every check records the status code and response time. Anything outside 200 to 399, or no answer within 10 seconds, counts as down.

## A heartbeat from inside the box

 /usr/local/bin/vps-heartbeat 

```bash
#!/bin/sh
# Pings Logdash only while the disk has room and the app answers locally.
# Cron starts it once a minute; it pings six times, 10 seconds apart,
# because a Pro push monitor expects a ping in every 15-second window.
PING_URL="https://api.logdash.io/ping/YOUR_MONITOR_ID"
APP_URL="http://127.0.0.1:3000/health"

for i in 1 2 3 4 5 6; do
  used=$(df --output=pcent / | tail -n 1 | tr -dc '0-9')
  if [ "$used" -lt 90 ] && curl -fsS -m 2 -o /dev/null "$APP_URL"; then
    curl -fsS -m 2 -o /dev/null -X POST "$PING_URL"
  fi
  sleep 10
done

# chmod +x /usr/local/bin/vps-heartbeat, then crontab -e:
# * * * * * /usr/local/bin/vps-heartbeat
```

Push monitors are a Pro feature. The script folds two checks into one signal: when the root disk passes 90% or the app stops answering on localhost, the pings stop and the monitor goes down. Add a memory or load check the same way. The df flags are GNU, so this runs as is on Debian and Ubuntu. One missed 15-second window is an alert, so a short network blip shows up as a down and up pair. That is the cost of hearing about real problems within 30 seconds.

## VPS monitoring tool for the box itself

Graphs of CPU, memory and disk over time are an agent job: Netdata, Beszel, or the provider agent on DigitalOcean. Logdash does not install one. Keep the agent for diagnosis and the outside check for the alert, because an agent on a box that has stopped cannot report its own death unless something outside expects to hear from it.

1. **Watch it from outside** Create a service in Logdash and point an HTTP monitor at https://yourapp.com/health. This part runs on the free plan.
2. **Add the heartbeat** On Pro, create a push monitor, put its id in the script, make it executable and add the crontab line. The monitor turns green within a minute.
3. **Trip the threshold** Change 90 to 1 in the script so the disk check fails. The pings stop, the push monitor goes down within 30 seconds, and a Telegram alert lands saying no call was received for this time range.

### Logdash vs Uptime Kuma

| Feature                 | Logdash                                               | Uptime Kuma                                      |
| ----------------------- | ----------------------------------------------------- | ------------------------------------------------ |
| Where the checker runs  | Hosted, outside your server                           | A server you run, ideally not the one it watches |
| Free tier               | Five HTTP monitors every 5 minutes                    | As many monitors as the box can handle           |
| Heartbeats from the box | Pro only, $15 a month                                 | Push monitors included                           |
| Disk, memory and CPU    | No agent, you script the threshold into the heartbeat | Not collected either                             |
| Monitor types           | HTTP and push                                         | HTTP, TCP, ping, DNS, keyword and more           |
| Maintenance             | Nothing to update                                     | Container updates, backups and its own uptime    |

### When Uptime Kuma is the better pick

- You already pay for a second server at a different provider. Kuma on that box watches the first one for free.
- You need TCP or ping checks on things that do not speak HTTP, such as SSH or a game server.
- You want dozens of monitors and are happy to own the box they run on.

### What is the best VPS monitoring tool? 

Two tools, not one. An outside uptime monitor for "is it answering", and an agent such as Netdata or Beszel, or your provider agent, if you want CPU, memory and disk graphs. Logdash covers the first and folds disk or memory thresholds into a heartbeat, but it runs no agent.

### Is there free VPS monitoring? 

Yes. The Logdash free plan checks five URLs every 5 minutes with Telegram alerts. Uptime Kuma is free if you have a second server to run it on. Heartbeats from inside the box need Logdash Pro.

### How does VPS uptime monitoring work? 

A server somewhere else requests a URL on your VPS on a schedule and records the status code and response time. Anything outside 200 to 399, or a timeout, flips the monitor to down and sends the alert.

### Can I run VPS monitoring on the VPS itself? 

For resource graphs, yes. For uptime, no: a monitor on the same box goes down with it and never sends the alert. Run the uptime check from outside, or at least from another provider.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Homelab monitoring](https://logdash.io/monitor/homelab): Homelab monitoring needs two layers, detailed checks inside the lab, usually Uptime Kuma, and one watcher outside it, because a monitor that shares your power, router and internet line goes silent exactly when those fail.

[Raspberry Pi uptime monitor](https://logdash.io/monitor/raspberry-pi): Have the Pi send a heartbeat out to a hosted monitor every 10 seconds from cron, so a crash, a power cut or a dead home connection all end the same way: the heartbeats stop and an alert reaches your phone.

[WordPress uptime monitoring](https://logdash.io/monitor/wordpress): Point an outside HTTP monitor at a URL that has to run PHP and reach MySQL, not only the cached homepage, and send the alert somewhere you read within minutes; no plugin is required.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.
