Master Uptime Kuma for self-hosted monitoring. Learn to track your VPS health and service uptime using Docker with this straightforward deployment guide.
When my primary API went down at 3 AM last month, I didn’t find out from an alert—I found out because a user emailed me. That's the kind of wake-up call that forces you to prioritize infrastructure observability, so I finally stopped relying on external SaaS tools and built my own.
If you’re running a small cluster of VPS instances, you don’t need a complex enterprise stack to know when your services are flapping. I’ve found that a simple Uptime Kuma instance, containerized and running on a dedicated monitoring node, is usually all you need to keep tabs on your stack.
Most developers start by using free tiers of hosted status pages. They work fine until you hit a rate limit or your monitoring provider has an outage of their own. By moving to self-hosted monitoring, you gain total control over your data and avoid the recurring costs of premium alerts.
I’ve been running my current setup for about six months now. It handles roughly 40 different endpoints across three regions. It’s lightweight, it doesn't phone home, and it integrates perfectly with the tools I already use to manage my containers.
Before you dive in, make sure you have Docker and Docker Compose installed on your target machine. I prefer using a dedicated, low-resource VPS (1 vCPU, 1GB RAM is plenty) to ensure the monitoring stack stays alive even if my primary application nodes go down.
Here is the docker-compose.yml file I use for my production deployment:
YAMLversion: '3.8' services: uptime-kuma: image: louislam/uptime-kuma:latest container_name: uptime-kuma restart: always volumes: - ./data:/app/data ports: - "3001:3001" networks: - monitoring networks: monitoring: driver: bridge
Once you’ve saved this, run docker-compose up -d. You’ll have a dashboard running on port 3001 within seconds.
The real value of Uptime Kuma isn't just the pretty dashboard; it’s the alerting integration. I’ve connected mine to a private Discord channel and Telegram bot, which ensures I get notified before the users do.
When tracking VPS health, don’t just ping the IP address. A server can respond to a ping while the application process is dead. Instead, configure "HTTP(s)" monitors that hit a /health or /status endpoint in your application.
Here’s a quick checklist for effective monitoring:
If you are managing complex traffic routing, you might want to look into how I handle Blue-Green Deployment for VPS: Managing Traffic with Traefik to ensure that your health checks are actually hitting the traffic-ready version of your app.
I initially tried to build a custom monitoring solution using shell scripts and Cron jobs. It was a disaster. The scripts were brittle, the logging was non-existent, and managing the state across multiple servers was a nightmare.
Switching to a containerized Docker deployment solved those issues instantly. However, there’s one caveat: you must monitor the monitor. If the server hosting Uptime Kuma goes down, you’re flying blind. I eventually solved this by adding a secondary, ultra-cheap "heartbeat" script on a different provider that alerts me if the monitoring node itself stops responding.
For those managing inter-node communication, I highly recommend looking at WireGuard Mesh Networking: Secure Your VPS Cluster Communication to keep your monitoring traffic private and secure across different data centers.
Is this the most robust system in the world? No. But for a solo engineer or a small team, it provides the visibility required to sleep through the night.
I’m still tinkering with my alerting logic—specifically, I want to implement a "maintenance mode" that integrates with my CI/CD pipeline so I don't get paged every time I push a deployment. If you decide to go down this route, start small. Monitor your core endpoints first, verify the alerts actually reach your phone, and build out from there.
There’s no perfect setup, just one that works well enough to prevent the "oops, the server is dead" email from your boss.
Does Uptime Kuma support monitoring private network services? Yes. Since it runs in a Docker container, you can attach it to the same Docker network as your other services or use a VPN/Mesh network to reach internal IPs.
How much storage does it need? Very little. The database (SQLite) grows slowly. I’ve been running it for months and the data folder is under 50MB.
Can I use this to monitor server resources like CPU and RAM? Uptime Kuma is primarily for service availability. For deep resource metrics, you’d be better served by something like Prometheus/Grafana or Implementing Laravel Pulse for Real-Time Infrastructure Monitoring if you’re already in the PHP ecosystem.
GitHub Actions self-hosted runners don't have to be permanent servers. Learn how to build ephemeral, auto-scaling Docker runners to save time and money.