A client once messaged me asking why their site had been down for "a couple of hours." I had no idea it was down — I found out from the client, not from any alert. That was embarrassing enough that I set up proper monitoring that same afternoon and haven't let it slide since.
Uptime Kuma is what I use now. It runs on my server, checks my sites and services every minute, and notifies me via Telegram the moment anything goes down. It also keeps response time history so I can see if latency was creeping up before an outage.
The setup takes about 15 minutes and is one of the better investments of time in the self-hosting toolkit — because you'd rather know about problems before your users do.
This guide deploys Uptime Kuma using Docker on Ubuntu 22.04 with Nginx and HTTPS.
I run Uptime Kuma on Tencent Cloud Lighthouse. It uses minimal resources — even on the entry-level plan, Uptime Kuma runs comfortably alongside your other applications. For Docker-based installations (the approach in this guide), select Lighthouse's Docker CE application image when creating your instance — Docker is pre-installed and you skip the setup step entirely. For monitoring, the server's global data center coverage (US, Europe, Asia-Pacific) lets you run the monitor from a location that gives a realistic latency reading for your target audience.
- Key Takeaways
| Monitor Type | What it checks |
|---|---|
| HTTP/HTTPS | Returns expected status code |
| TCP Port | Port is open and accepting connections |
| Ping (ICMP) | Host responds to ping |
| DNS | Domain resolves correctly |
| Docker Container | Container is running |
| Steam Game Server | Game server is online |
| Database (MySQL, PostgreSQL, MongoDB, Redis) | Connection succeeds |
| JSON Query | API response contains expected value |
| Certificate Expiry | SSL certificate valid and expiry days |
| Requirement | Notes |
|---|---|
| Cloud server | Tencent Cloud Lighthouse Ubuntu 22.04 |
| Docker | Installed |
| Nginx | For reverse proxy |
| A domain name | For HTTPS access |
ssh ubuntu@YOUR_SERVER_IP
# Create app directory
mkdir -p ~/apps/uptime-kuma && cd ~/apps/uptime-kuma
Create docker-compose.yml:
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "3001:3001"
volumes:
- uptime-kuma_data:/app/data
environment:
- TZ=America/New_York # Set your timezone
volumes:
uptime-kuma_data:
Start it:
docker compose up -d
docker compose logs -f uptime-kuma
# Wait for: Listening on 3001
sudo apt install -y nginx
sudo nano /etc/nginx/sites-available/uptime-kuma
server {
listen 80;
server_name status.yourdomain.com;
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
# WebSocket support (Uptime Kuma uses WebSockets for real-time updates)
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
proxy_read_timeout 86400s;
}
}
sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/
sudo ufw allow 'Nginx Full'
sudo ufw allow ssh
sudo ufw enable
sudo nginx -t && sudo systemctl reload nginx
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d status.yourdomain.com
Visit https://status.yourdomain.com.
The dashboard shows all your monitors at a glance — green for up, red for down, with uptime percentages and response time graphs.
Click Add New Monitor.
Monitor Type: HTTP(s)
Friendly Name: My Blog
URL: https://yourdomain.com
Heartbeat Interval: 60 seconds (check every minute)
Retries: 2 (retry before marking as down)
Heartbeat Retry Interval: 20 seconds
HTTP Status Code: 200 (or whatever your site returns)
Monitor Type: TCP Port
Friendly Name: PostgreSQL
Host: localhost (or server IP)
Port: 5432
Interval: 120 seconds
Monitor Type: Docker Container
Friendly Name: Ghost Blog
Container Name: ghost
Requires Uptime Kuma to have access to the Docker socket. Update docker-compose.yml:
uptime-kuma:
volumes:
- uptime-kuma_data:/app/data
- /var/run/docker.sock:/var/run/docker.sock:ro # Add this
Monitor Type: DNS
Friendly Name: Domain DNS
Hostname: yourdomain.com
Resolver Server: 8.8.8.8
Record Type: A
Set up notifications before a problem occurs, not after.
Go to Settings → Notifications → Add Notification.
/newbothttps://api.telegram.org/botTOKEN/getUpdatesNotification Type: Email (SMTP)
Server: smtp.mailgun.org
Port: 587
Username: postmaster@mg.yourdomain.com
Password: your SMTP password
To: your@email.com
Discord, Slack, Microsoft Teams, PagerDuty, OpsGenie, Pushover, Signal, WhatsApp (via Twilio), webhooks, and more.
Click Test on the notification setup page to verify it works before you need it.
Uptime Kuma can generate a public status page — useful for communicating service status to your users.
status (accessible at https://status.yourdomain.com/status/status)Users can subscribe to status page notifications directly.
Uptime Kuma's data (monitors, notifications, history) is in a SQLite database inside the Docker volume.
# Manual backup
docker run --rm \
-v uptime-kuma_uptime-kuma_data:/data \
-v ~/backups/uptime-kuma:/backup \
alpine cp /data/kuma.db /backup/kuma_$(date +%Y%m%d).db
# Automated backup
mkdir -p ~/backups/uptime-kuma
(crontab -l; echo "0 4 * * * docker run --rm -v uptime-kuma_uptime-kuma_data:/data -v ~/backups/uptime-kuma:/backup alpine cp /data/kuma.db /backup/kuma_\$(date +%Y%m%d).db") | crontab -
Setting a very aggressive check interval (e.g., 30 seconds) with low retry counts can generate false positive alerts. A momentary blip in network connectivity triggers a "down" notification, then the site recovers before you even see the alert.
Recommended settings for production:
Heartbeat Interval: 60 seconds
Retries: 3 (marks as down only after 3 consecutive failures)
Heartbeat Retry Interval: 30 seconds
This means a site must fail 3 consecutive checks (3 × 30 seconds = 90 seconds of downtime) before triggering a notification. Reduces noise significantly.
For critical services where you need faster notification, use 30-second intervals but keep retries at 2-3.
HTTP/HTTPS → Check website returns expected status code
TCP Port → Verify port is open (databases, game servers)
Ping → Basic connectivity check
DNS → Domain resolution check
Docker → Container running check
Steam → Game server availability
Push → Monitor sends heartbeat TO Uptime Kuma
MySQL, PostgreSQL, MongoDB, Redis → DB connection check
MQTT → IoT message broker
JSON Query → API returns expected value
Certificate → SSL cert expiry warning
| Issue | Likely Cause | Fix |
|---|---|---|
| Connection refused | Service not running or wrong port | Check systemctl status SERVICE and verify firewall rules |
| Permission denied | Wrong file ownership or permissions | Check file ownership with ls -la and use chown/chmod to fix |
| 502 Bad Gateway | Backend service not running | Restart the backend service; check logs with journalctl -u SERVICE |
| SSL certificate error | Certificate expired or domain mismatch | Run sudo certbot renew and verify domain DNS points to server IP |
| Service not starting | Config error or missing dependency | Check logs with journalctl -u SERVICE -n 50 for specific error |
| Out of disk space | Logs or data accumulation | Run df -h to identify usage; clean logs or attach CBS storage |
| High memory usage | Too many processes or memory leak | Check with htop; consider upgrading instance plan if consistently high |
| Firewall blocking traffic | Port not open in UFW or Lighthouse console | Open port in Lighthouse console firewall AND sudo ufw allow PORT |
How much resource does Uptime Kuma use on the server?
Uptime Kuma is designed to be lightweight. It typically uses minimal CPU and 50–200 MB RAM. Run it on the same server as your applications without significant impact.
How do I get alerts when a service goes down?
Configure Uptime Kuma's notification integrations — most support email, Telegram, Slack, Discord, and webhook. Set appropriate check intervals (every 60 seconds is typical) and recovery thresholds to avoid alert fatigue from brief glitches.
Can I monitor multiple servers with one Uptime Kuma instance?
Yes. Add the server IPs or domains as separate monitors. For agent-based monitoring, install the agent on each server you want to track.
How do I monitor SSL certificate expiry?
Add a certificate check to your monitoring. Most monitoring tools including Uptime Kuma support HTTPS checks that alert when certificates are within a configurable days-to-expiry threshold.
Monitor your services today:
👉 Tencent Cloud Lighthouse — Run Uptime Kuma alongside your apps
👉 View current pricing and promotions
👉 Explore all active deals and offers