5 myths about self-hosted uptime monitoring (from someone who ran it on the same VPS)

Self-hosting a monitoring tool is a rite of passage. You spin up a container, add your sites, get a nice dashboard with green bars, and feel in control. Open-source monitors are genuinely good, and plenty of people run them well.

But there are a few beliefs about self-hosted monitoring that sound right and cause real gaps. Here are five, with fixes.

Myth 1: "Running the monitor on the same server is fine"

This is the big one. If your monitor lives on the same VPS as your app, what happens when the VPS goes down?

The monitor goes down too. No alert is sent, because the thing that sends alerts is off. Your dashboard shows a gap, which you see when you log in later, after customers have already told you.

The same applies to anything shared: the same host, the same Docker network, the same cloud region, the same provider account.

Reality: a monitor has to fail independently of what it watches. At minimum, put it on a different machine with a different provider. If that's not possible, add an external check on the monitor itself (see myth 5).

Myth 2: "localhost checks tell me my site is up"

A check like this feels reassuring:

curl -fsS http://localhost:3000/health

But it skips DNS, TLS, your reverse proxy, your firewall, your CDN and the public network. Every one of those can break while localhost happily returns 200.

A quick illustration of how many layers sit in between:

# What localhost tests curl -fsS http://127.0.0.1:3000/health # What your users actually do curl -fsS --max-time 10 https://www.example.com/health \ -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n'

The second command goes through DNS resolution, a TCP connection to your public IP, a TLS handshake and your proxy. If any step fails, it fails.

Reality: localhost checks are fine for process health. User-facing monitoring must use the public URL from outside your network.

Myth 3: "If the dashboard is green, alerts are working"

Your monitor can detect an outage perfectly and still tell nobody. Common reasons:

The SMTP credentials expired, so alert emails fail silently.
The chat webhook was deleted when someone cleaned up channels.
Notifications were muted "temporarily" during maintenance and never unmuted.
The phone app's push token expired after a reinstall.

Self-hosted setups are especially prone to this because nobody else is maintaining the notification integrations.

Reality: test alert delivery on a schedule. Create a check that is meant to fail, like a URL that always returns 500, and make sure the alert arrives. Then pause it.

# A tiny always-failing endpoint for alert tests python3 -c 'from http.server import * class H(BaseHTTPRequestHandler): def do_GET(s): s.send_response(500); s.end_headers() HTTPServer(("0.0.0.0", 8099), H).serve_forever()'

Myth 4: "One location is enough"

Most self-hosted monitors run from one place: wherever you installed them. That creates two problems.

First, false alarms. If the network between your monitor and your site hiccups, you get an alert even though users are fine. After a few of those, people start ignoring alerts.

Second, blind spots. Problems that affect only some regions (DNS propagation, routing issues, a CDN edge) are invisible from a single location that happens to be fine.

Reality: use at least two locations and alert when both agree. If you self-host, run two small instances in different regions or providers. Or combine your self-hosted monitor with an external service for the outside view.

Myth 5: "Nobody needs to watch the watcher"

Your monitor is software. It needs updates, disk space, memory and a working database. When it fails, it usually fails quietly. A full disk, a crashed container, an expired certificate on its dashboard: none of these page anyone.

Reality: have something external check your monitor. The simplest version is a heartbeat. Your monitor pings an external URL every few minutes, and an alert fires if the pings stop:

# crontab on the monitoring server */5 * * * * curl -fsS --max-time 10 https://heartbeat.example.com/ping/monitor-01 > /dev/null

Or flip it around: point an external uptime check at your monitor's own dashboard URL.

So should you self-host?

Yes, if you enjoy it and want control. Self-hosted monitors are great for internal services, private networks, and things no external service can reach.

Just design around the myths:

Concern	Fix
Shared failure	Run on separate infrastructure
Localhost-only checks	Check public URLs from outside
Silent alert failures	Scheduled alert tests
Single location	Two locations, or add an external service
Monitor dies quietly	External heartbeat or check on the monitor

Many teams end up with a hybrid: self-hosted for internal checks, and an external service like upordown.online for public URLs and for watching the self-hosted monitor itself. That gives you control and an independent view.