Monitoring Isn't Just "Installing a Tool"
Many sites install a monitoring tool right after launch, but installing isn't the same as actually monitoring. Effective monitoring answers three questions: what metrics to watch, how to notify when something's off, and who handles the alert when it fires. This guide ties the whole configuration together. Read it alongside Prometheus + Grafana basics and monitoring & alerting overview to cover everything from a single host to a multi-server fleet.
Key Metrics to Monitor
| Metric | What to Check | Alert Threshold | Check Frequency |
|---|---|---|---|
| Uptime | Site accessible? | 1 failed check | Every 1-5 minutes |
| Response Time | Server response speed | > 3 seconds | Every 5 minutes |
| SSL Certificate | Days until expiry | < 30 days | Daily |
| Disk Usage | Storage remaining | > 85% | Every 30 minutes |
| Memory Usage | RAM consumption | > 90% | Every 30 minutes |
| CPU Load | Processor utilization | > 80% sustained | Every 5 minutes |
| Database | Connection status | Connection failure | Every 5 minutes |
Monitoring Tools Comparison
| Tool | Type | Price | Best For |
|---|---|---|---|
| Uptime Kuma | Self-hosted | Free | Small-medium sites |
| Better Uptime | SaaS | Free / $20/mo | Team with on-call |
| Checkly | SaaS | Free / $30/mo | API + Browser monitoring |
| Datadog | SaaS | $15/host/mo | Enterprise full-stack |
| Grafana + Prometheus | Self-hosted | Free | Advanced infrastructure |
| Netdata | Self-hosted | Free | Real-time server metrics |
Recommended Monitoring Stack
For Small Sites (Free)
Uptime Monitoring: Uptime Kuma (self-hosted)
Server Metrics: Netdata (one-liner install)
SSL Check: Uptime Kuma built-in
Notifications: Telegram / Email
For Medium Sites ($0-30/month)
Uptime Monitoring: Better Uptime or Checkly
Server Metrics: Netdata or basic Prometheus
APM: Sentry (free tier for errors)
Logs: Simple log rotation + manual check
Notifications: Slack / Telegram / Email
For Enterprise ($$$)
Uptime: Datadog / Pingdom
Metrics: Grafana + Prometheus
APM: Datadog APM / New Relic
Logs: ELK Stack / Loki
Notifications: PagerDuty / Opsgenie
Alert Notification Channels
| Channel | Cost | Urgency | Best For |
|---|---|---|---|
| Free | Low | Daily summaries, reports | |
| Telegram | Free | Medium | Real-time alerts, team chat |
| Slack | Free | Medium | Team collaboration |
| Discord | Free | Medium | Dev community channels |
| SMS | Paid | High | Critical issues |
| Phone Call | Paid | Highest | P0 incidents |
Alert Configuration Tips
1. Set Up Alert Escalation
First alert → Telegram/Slack (immediate)
No response in 15 min → SMS
No response in 30 min → Phone call
2. Configure Maintenance Windows
- Exclude scheduled maintenance from alerting
- Set quiet hours for non-critical alerts (e.g., 10 PM - 8 AM)
3. Avoid Alert Fatigue
- Don't alert on every small event
- Use hysteresis (e.g., alert only if 3 consecutive failures)
- Group related alerts
Alert Message Template
A good alert lets the on-call engineer judge priority without opening any page. Include: subject (what it is), impact (who it affects, how severe), evidence (current value vs. threshold), and action (which command to run first). For example: Disk usage 92% (threshold 85%) - host web-01 - run df -h first to find which mount. Baking the template into the rule beats writing explanations afterwards.
Monitoring Checklist
- Uptime monitoring configured (5-min intervals)
- SSL certificate expiry alert (< 30 days)
- Disk usage alert (> 85%)
- Memory usage alert (> 90%)
- Database connection monitoring
- Notification channel configured (Telegram/Slack/Email)
- Maintenance windows defined
- Alert escalation policy documented
- Dashboard created for key metrics
- Incident response plan documented
Uptime Kuma Notification Settings
Uptime Kuma natively supports Telegram, Slack, Discord, email, and many other channels, plus alert escalation policies and quiet-time configuration. In a monitor's settings, enable notifications and bind the channel's webhook. For full deployment details, see the Uptime Kuma deployment guide.
A Real-World Incident
A forum site had been live for six months without database monitoring. One night the database connection pool filled up, and the homepage returned 502 for 20 minutes — discovered only after users complained in the support group. Afterwards, three things were added: a database connection probe every 5 minutes, a P1 alert when the error rate stayed above 2% for 10 minutes, and a Telegram on-call group with phone escalation after 30 minutes of no response. When the same pool issue recurred, the on-call engineer had it restarted and scaled within 12 minutes. Monitoring's value isn't avoiding failures — it's compressing discovery time from "user reports it" to "minutes."
FAQ
How should I set alert thresholds? Let monitoring run for a week or two to observe the normal baseline, then set thresholds at 1.2-1.5x that baseline; don't blindly copy recommended values from the internet.
Are more tools and more monitors always better? No. Pile on too many tools and fire too many alerts, and the on-call team goes numb. Cover the critical path first, then expand gradually.
Does a small site need a full ELK stack? No. Being able to search logs and get disk warnings is enough; move to an ELK platform or Loki when log volume actually demands it.
Reference: Uptime Kuma notification docs — https://github.com/louislam/uptime-kuma ; Checkly docs — https://checklyhq.com/docs/ ; Datadog docs — https://docs.datadoghq.com/