Uptime monitoring answers one question, continuously: can my users reach my service right now? It checks your websites, APIs, servers and scheduled jobs from the outside, and alerts you before customers notice. Here’s what to monitor, and how the popular self-hosted and hosted tools compare.
What to monitor
| Check | Catches |
|---|---|
| HTTP(S) status and keyword | Site down, errors, a broken page (look for a word that must appear) |
| Response time | Slowdowns before they become outages |
| TLS certificate expiry | Expired certificates. See SSL expiry checks |
| TCP port | Database, mail, game server, SSH reachability |
| Ping (ICMP) | Host reachability |
| DNS | Records changed or resolution failing |
| Heartbeat / cron monitoring | Backups and jobs that silently stop running |
| Domain expiry | Forgotten renewals |
Heartbeat monitoring is often overlooked and very valuable: your backup script pings a URL when it finishes, and you get alerted if the ping doesn’t arrive. See database backup automation.
Self-hosted tools
| Tool | Highlights | Notes |
|---|---|---|
| Uptime Kuma | Beautiful UI, many check types, status pages, 90+ notification channels | The most popular self-hosted option. See Uptime Kuma |
| Gatus | Config-as-code (YAML), conditions on status, body and response time, status page | Great for GitOps |
| Healthchecks.io (self-hosted) | Cron and heartbeat monitoring specialist | Open source, also offered as SaaS |
| Statping-ng, Upptime | Status pages | Upptime runs entirely on GitHub Actions |
| Prometheus blackbox_exporter | HTTP, TCP, ICMP and DNS probes into Prometheus | Fits existing Prometheus setups. See node_exporter |
| Zabbix web scenarios | Multi-step HTTP checks | If you already run Zabbix. See Zabbix |
Hosted (SaaS) tools
UptimeRobot, Better Stack (Better Uptime), Pingdom, StatusCake, Freshping, Checkly (synthetic browser checks) and others. Benefits: probes from many regions, no infrastructure to maintain, and they keep working when your infrastructure is down.
The golden rule: monitor from outside
A monitor running on the same server, or in the same data centre, as the thing it watches goes down with it, and can’t alert you. Options:
- run Uptime Kuma or Gatus on a separate small VPS in a different location from your production servers. See choosing a VPS location;
- or use a SaaS monitor for external checks, and self-hosted tools for internal ones;
- monitor the monitor: a free SaaS heartbeat or HTTP check on your self-hosted monitoring instance.
Alerting that works
- Route alerts where you’ll see them: phone push (ntfy, Pushover, Telegram), Slack or Discord, email for low priority.
- Require 2–3 consecutive failures, or checks from several locations, before alerting, which avoids false alarms from network blips.
- Send recovery notifications too.
- Define who responds, and keep a short runbook: where the logs are, how to restart, how to fail over. See high availability.
Status pages
A public status page (Uptime Kuma, Gatus, Upptime, Better Stack, Instatus) reduces support load during incidents, and builds trust. Host it separately from your main infrastructure, so it stays up during outages.
Beyond uptime
Uptime monitoring tells you that something is wrong. For why, you need metrics and logs: Prometheus and Grafana, Netdata and Loki.
A practical small-team setup
- Uptime Kuma on a separate small VPS: HTTP checks plus keyword checks for each site, TLS expiry, TCP checks for databases (via a VPN), and heartbeats for backup jobs.
- A free SaaS check watching Uptime Kuma itself.
- Alerts to a Telegram or Slack channel plus phone push for critical services.
- A public status page for customers.
Quick reference
| Need | Suggested tool |
|---|---|
| Easiest self-hosted | Uptime Kuma |
| Config in Git | Gatus |
| Cron and backup jobs | Healthchecks |
| Already on Prometheus | blackbox_exporter |
| Multi-region, zero maintenance | SaaS monitor |
Related: server security monitoring and Zabbix.