Uptime monitoring alerts you the moment your website or application goes down — ideally before your users notice and report it. This guide covers both external monitoring services and self-hosted options.
Why External Monitoring Matters
Server-based monitoring tools (Netdata, Prometheus) can't alert you if the entire server is unreachable. External monitoring, checking from outside your infrastructure, catches total outages that internal tools miss.
What to Monitor
- Your main website/homepage
- Critical API endpoints, especially any
/healthendpoints — see How to Add Health Check Endpoints to Your Application - SSL certificate expiry
- DNS resolution
Option 1 — Third-Party Uptime Monitoring Services
Many services offer free tiers checking your site every few minutes from multiple global locations, alerting via email, SMS, or messaging integrations when downtime is detected. Setup typically involves:
- Sign up and add your URL as a monitor
- Configure check interval (e.g. every 1–5 minutes)
- Set up alert channels (email, SMS, Slack, etc.)
- Optionally configure a public status page
Option 2 — Self-Hosted Uptime Monitoring (Uptime Kuma)
For a self-hosted alternative with a modern dashboard:
docker run -d --restart=unless-stopped -p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:1Access at http://YOUR_SERVER_IP:3001 and add monitors through the web UI.
Important: host this monitoring instance on a different server than what you're monitoring — if the monitored server goes down, a monitor running on that same server can't alert you.
Setting Up Simple DIY Monitoring with Cron
For a minimal approach without a dedicated tool:
sudo nano /usr/local/bin/check-uptime.sh#!/bin/bash
URL="https://yourdomain.com"
STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$URL")
if [ "$STATUS" -ne 200 ]; then
echo "Site down! Status: $STATUS" | mail -s "ALERT: Site Down" [email protected]
fisudo chmod +x /usr/local/bin/check-uptime.sh
sudo crontab -e*/5 * * * * /usr/local/bin/check-uptime.shThis requires a working mail setup on the monitoring server to send alerts — and again, should run from a server independent of the one being monitored.
Monitoring SSL Certificate Expiry
#!/bin/bash
EXPIRY=$(echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
echo "Certificate expires: $EXPIRY"Most third-party uptime monitoring services also include SSL expiry monitoring built in, avoiding the need for a custom script.
Setting Up a Public Status Page
Many monitoring tools (including self-hosted Uptime Kuma) can generate a public-facing status page — useful for transparently communicating incidents to your users during an outage.
Common Errors
False positive alerts during brief network blips — most monitoring tools support requiring multiple consecutive failed checks before alerting, reducing noise from transient issues.
No alert received despite actual downtime — verify the alert channel (email/SMS) is correctly configured and test it deliberately by simulating a failure.
Best Practices
- Always monitor from infrastructure independent of what you're monitoring
- Check from multiple intervals/thresholds to avoid alert fatigue from transient blips
- Monitor SSL expiry alongside uptime — an expired certificate is effectively downtime for most visitors
Related Articles
- How to Add Health Check Endpoints to Your Application
- Website Down? A Step-by-Step Troubleshooting Checklist
- How to Renew and Auto-Renew Let's Encrypt Certificates
