A VPS running MQTT, dashboards and remote access for a genuine IoT deployment needs something watching it independently, since the VPS itself can’t reliably alert you that it’s down. Uptime Kuma, a free, self-hosted monitoring tool, checks every service on the VPS and can monitor individual devices’ heartbeats too, alerting through 90+ notification channels the moment something stops responding, for no recurring cost beyond the small amount of VPS capacity it uses.
The problem this solves
Every guide on this site assumes a VPS staying reliably up, but “reliably” isn’t “guaranteed”, hardware fails, software crashes, a misconfiguration locks up a service. For a hobby project, brief downtime is an inconvenience. For genuine 24/7 IoT operations, industrial monitoring, cold chain alerting, a business’s remote access infrastructure, undetected downtime means exactly the failure mode every other guide on this site was built to prevent: a problem going unnoticed because the system meant to catch it has itself silently stopped working.
Why monitoring needs to be independent of what it’s monitoring
A genuinely important principle, easy to overlook: monitoring software running on the same VPS it’s checking has an obvious blind spot, if the entire VPS goes down, the monitoring goes down with it, with nothing left to send the alert. The most robust setup, covered in more depth later in this guide, runs the monitoring tool on a separate, second VPS specifically so a single point of failure on the primary infrastructure doesn’t also take out the alarm system meant to report that failure.
Installing Uptime Kuma
docker run -d --restart=always -p 3001:3001
-v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2Uptime Kuma listens on port 3001 by default, following the same reverse-proxy and HTTPS pattern covered throughout this site’s other guides before exposing it externally. The web interface walks through creating an admin account on first visit, then adding monitors.
What to actually monitor on an IoT VPS
- HTTP(S) checks for any web-facing service, a ThingsBoard or Grafana dashboard, confirming it responds correctly, not just that the server is technically reachable.
- TCP port checks for non-web services like the MQTT broker’s port (1883 or 8883), confirming Mosquitto is actually accepting connections.
- Ping checks for basic reachability of the VPS itself and, where relevant, any other infrastructure like a separate database server.
- Push/heartbeat monitors, a genuinely valuable monitor type for IoT specifically: rather than Uptime Kuma checking a service, the monitored thing itself calls out to Uptime Kuma on a schedule, with an alert firing if that expected call-in doesn’t arrive. This is the right pattern for confirming a device or a scheduled job, a backup script, a Node-RED flow, actually ran, not just that a service is technically listening.
Setting up alerts that actually reach you
Uptime Kuma supports notification delivery through more than 90 services, email, Telegram, Slack, Discord, Pushover and many others, configurable per monitor so a critical service can alert through multiple channels simultaneously while a less critical one uses just one. For genuinely important infrastructure, redundant notification channels, email plus a phone-based push notification service, mean a single channel’s own outage (an email provider having issues, for example) doesn’t silently swallow the alert.
Public status pages: a genuinely useful side benefit
Beyond personal alerting, Uptime Kuma’s status page feature, a shareable public or password-protected page showing current and historical uptime, is worth setting up for anyone running infrastructure other people depend on, a client whose CCTV or remote access depends on your VPS, or a business partner relying on a shared dashboard. Rather than fielding “is it down for you too?” messages individually, a status page gives a single, always-current source of truth anyone can check themselves.
A worked example: monitoring a multi-site industrial deployment
For the kind of deployment covered in Multi-Site Industrial IoT Data Aggregation, Uptime Kuma’s push/heartbeat monitors are particularly well suited: each site’s local gateway calls in on a schedule, with a missed call-in flagged per site individually, giving exactly the kind of “which specific site has gone quiet” visibility that a single, generic “is the VPS up” check wouldn’t provide on its own.
The honest limitation worth knowing about
Uptime Kuma checks from a single location, your monitoring VPS, which means if that VPS’s own network connection has a problem, monitoring stops even if everything it’s watching is genuinely fine, a false negative rather than a false positive but still worth knowing. Commercial, distributed monitoring services check from multiple global locations specifically to rule this out; for most projects on this site’s scale, a single monitoring location is an acceptable trade for zero cost and full control, but it’s worth understanding the limitation rather than assuming Uptime Kuma’s view is infallible.
Where this VPS should actually sit
Running Uptime Kuma on a small, separate VPS from the infrastructure it’s monitoring, rather than alongside it, is genuinely worth the very modest extra cost for anything beyond a hobby project. LumaDock‘s smallest tier is more than adequate for this purpose, since Uptime Kuma’s own resource footprint is minimal even watching dozens of monitors.
Frequently asked questions
Is Uptime Kuma suitable for a team, or just a single person checking alerts?
Worth knowing as a genuine limitation: Uptime Kuma currently lacks multi-user accounts with role-based permissions, meaning anyone with dashboard access can change any setting. For a small team comfortable sharing one login, this is a minor inconvenience; for anything requiring stricter access control, it’s a real constraint to weigh.
Can Uptime Kuma monitor Docker containers directly, not just network services?
Yes, Uptime Kuma supports Docker container monitoring directly, useful for confirming a specific container (ChirpStack, ThingsBoard, or any other Docker-based service covered elsewhere on this site) is actually running, not just that the host VPS is reachable.
How does this relate to the backup strategies covered elsewhere on this site?
Directly and usefully: a backup script that finishes by calling Uptime Kuma’s push URL gives genuine confirmation backups are actually running on schedule, covered in more depth in Backup Strategies for Self-Hosted IoT Infrastructure, rather than just assuming a cron job is working because nobody’s complained.
Does setting up monitoring add meaningful security risk of its own?
Like any web-facing service, Uptime Kuma’s own interface should follow the same hardening discipline covered in the VPS Security Hardening Checklist, strong credentials, HTTPS via reverse proxy, and ideally access restricted to a VPN tunnel rather than the open internet given how much it reveals about your infrastructure’s topology.
Is there a cost to running monitoring on a second, dedicated VPS rather than the same one?
A small one, an additional entry-level VPS, typically a few pounds monthly, genuinely worth it for anything where undetected downtime carries real consequences, weighed against the alternative of monitoring sharing fate with whatever it’s meant to be watching.
Can Uptime Kuma check SSL certificate expiry too, not just service availability?
Yes, this is built in directly, alerting ahead of an expiring certificate, a genuinely common, entirely avoidable cause of unexpected service disruption when a Let’s Encrypt renewal silently fails and nobody notices until the certificate has already expired.
A realistic first monitoring setup, built incrementally
Rather than trying to monitor everything on day one, a sensible build order: add a single ping check for the main VPS first, confirm an alert actually arrives by deliberately stopping a service temporarily and watching the notification fire, then add monitors for each individual service (MQTT, the dashboard, any web-facing component) one at a time. This incremental approach, testing that alerting genuinely works at each step rather than configuring everything at once and assuming it’s correct, catches notification misconfigurations early, while they’re isolated to one monitor, rather than discovering during an actual outage that alerts were never correctly wired up in the first place.
Maintenance windows: avoiding alert fatigue during planned work
Uptime Kuma supports scheduling maintenance windows, periods where monitors pause and don’t fire alerts, worth using deliberately whenever performing planned work, a security update requiring a reboot, a service migration, that would otherwise trigger a flurry of false alarms. This is a small feature but a genuinely important one for keeping trust in the alerting system intact, since a history of alerts that turned out to be planned, expected downtime trains people to start ignoring alerts generally, exactly the outcome good monitoring discipline is meant to prevent.
Bringing monitoring into the rest of this site’s content
Every guide on this site that mentions “set up alerting” or “watch for X condition” is implicitly assuming something like the setup covered in this guide exists underneath it. Treating this guide as one of the first things to build, alongside or shortly after the core MQTT and dashboard infrastructure covered in VPS for IoT: The Complete Guide, rather than as an afterthought added once something has already gone wrong unnoticed, is the difference between monitoring that’s genuinely protective and monitoring that’s merely aspirational.
What to monitor on a per-project basis, not just the VPS itself
Uptime Kuma’s push/heartbeat monitor type deserves special attention for IoT specifically: rather than checking whether a service is running, it expects the thing being monitored to actively check in on a schedule. This is the right model for confirming that a Node-RED flow actually ran, that a scheduled backup completed, that a LoRaWAN device is still sending data at the expected interval. Silence, a missed check-in, becomes the alert rather than a failed connection attempt, which is a fundamentally different, often more useful signal for IoT deployments where the concern is “has this device gone quiet” rather than “is this web server up.”
Frequently asked questions
Is Uptime Kuma suitable for a team, or just a single person checking alerts?
Worth knowing as a genuine limitation: Uptime Kuma currently lacks multi-user accounts with role-based permissions, meaning anyone with dashboard access can change any setting. For a small team comfortable sharing one login this is manageable; for anything requiring stricter access control it’s a real constraint to weigh.
Can Uptime Kuma monitor Docker containers directly?
Yes, it supports Docker container monitoring directly, useful for confirming a specific container (ChirpStack, ThingsBoard, or any other Docker-based service) is actually running, not just that the host VPS is reachable.
Does this relate to the backup strategies covered elsewhere on this site?
Directly: a backup script that finishes by calling Uptime Kuma’s push URL gives genuine confirmation backups are running on schedule, covered in Backup Strategies for Self-Hosted IoT Infrastructure.
Does setting up monitoring add meaningful security risk?
Like any web-facing service, Uptime Kuma’s interface should follow the same hardening discipline in the VPS Security Hardening Checklist: strong credentials, HTTPS, and ideally access restricted to a VPN tunnel rather than the open internet.
Can Uptime Kuma check SSL certificate expiry too?
Yes, this is built in directly, alerting ahead of an expiring certificate, a common, entirely avoidable cause of unexpected service disruption when a Let’s Encrypt renewal silently fails and nobody notices until the certificate has already expired.
Setting realistic check intervals
Uptime Kuma supports check intervals as low as 20 seconds, but shorter intervals aren’t always better. For a VPS running IoT infrastructure, one-minute intervals are generally adequate for service-availability monitoring; the lag between a real outage and an alert is negligible at this cadence, and shorter intervals generate higher load on both the monitoring tool and the monitored services for no practical benefit. Reserve shorter intervals for things where second-level response genuinely matters, which for the projects covered on this site is uncommon. Setting retries to 2 or 3, meaning an alert only fires after consecutive failures rather than a single failed check, reduces false positives from transient network hiccups without meaningfully delaying genuine outage detection.
The status page as a client communication tool
For integrators running the multi-tenant ThingsBoard deployments covered elsewhere on this site, Uptime Kuma’s public status page feature earns its keep as more than internal monitoring: a shared status page URL given to each client means they can check “is the platform up” themselves during any connectivity issue, rather than generating a support call every time something seems slow. Configured with per-customer monitors and set to display only the relevant subset of services to each client, it becomes a basic service-level communication tool that costs nothing beyond the monitoring infrastructure already running.