Monitoring and Alerting

Why Monitoring Matters

A simple question: is your site online right now? Most people can answer. Next: how many requests in the past 24 hours took longer than 3 seconds? Most people can't. Monitoring isn't about proving nothing is wrong — it's about discovering problems you didn't know existed: a disk filling up at 2 AM, an origin timeout at 3 AM, both usually visible in the metric curves before any user notices.

AI Prompt Template

Create a website monitoring plan.
- Site URL: [URL] | Server: [VPS/Dedicated/Cloud]
- Tech Stack: [PHP/Node.js/Python]
- Alert via: [Email/Telegram/Slack]

Output: monitoring tool, metrics, thresholds, notification setup, incident response.

Three Non-Negotiable Metrics

Availability

The most basic metric: does the site return 200 OK? Send an HTTP probe from an external source every 1-5 minutes and check the response code. If three consecutive checks fail, trigger an alert. The "external" part matters — a self-test on the same server bypasses the datacenter network, DNS, and the public path, so it can't detect real user reachability problems.

Response Time

Users experience performance as response time. The 95th percentile (P95) is more useful than the average — averages get pulled down by a few very fast requests, while P95 reflects what most users actually experience.

Error Rate

HTTP 5xx errors won't hit zero — but sustained rates above 0.5% warrant investigation. A jump from 0.1% to 5% is either a server config issue or an upstream failure. Either way, investigate immediately.

Alert Design Principles

The goal isn't to handle every alert — it's to make sure the important ones don't get drowned out.

Severity Levels

P0 (Immediate, respond within 5 min):
  Site completely unavailable > 5 min

P1 (Urgent, respond within 30 min):
  P95 response time > 3s for 15 min
  Error rate > 2% for 10 min

P2 (Business hours):
  SSL certificate expires in < 30 days
  Disk usage > 85%

Alert Frequency

Never send the same alert repeatedly. If a problem persists, send once, confirm once, escalate once. Imagine being woken at 3 AM by a false alert — after it happens twice, you go numb. Alert fatigue is more dangerous than having no alerts at all.

Tool Comparison

For small to medium sites, start with Uptime Kuma + Grafana; don't deploy a full ELK stack on day one. For deeper practice, see the monitoring & alerting guide and Prometheus + Grafana basics.

Deploying Uptime Kuma

Simplest single-container setup:

docker run -d --name uptime-kuma --restart=always -p 3001:3001 louislam/uptime-kuma:latest

For production, use docker-compose with a mounted data directory so rebuilding the container doesn't wipe your monitor configuration:

version: '3'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    ports: ["3001:3001"]
    volumes: ["./data:/app/data"]
    restart: always

Full deployment and configuration details: Uptime Kuma deployment guide.

Alert Channels & Escalation

Configure an escalation policy: first alert goes to the real-time channel, escalate to SMS after 15 minutes with no response, and go to a phone call after 30 minutes. Also keep switches for maintenance windows and night-time quiet hours so scheduled maintenance isn't mistaken for an incident.

A Real-World Scenario

An e-commerce site set up 5-minute uptime probes with Uptime Kuma. Late one night it received a "three consecutive failed checks" alert. The on-call engineer opened Grafana and saw CPU was normal — but disk usage had climbed from 60% to 96% after 10 PM: log files had filled the data volume. Because the alert path was clear (availability → disk metric → root cause), the site recovered in 40 minutes. Without monitoring, that problem would most likely have waited until the next morning, when users reported "the site is down."

Alert Noise-Reduction Checklist

The more precise the alerts, the more willing on-call people are to read them. Audit against this list:

• Every alert must imply a clear action (what to check, what to fix, who to call);
• Don't re-push the same issue within 24 hours — update its status instead;
• Only P0/P1 at night; leave P2 for business hours;
• Clean up obsolete rules once a quarter.

Combined with alert fatigue & on-call practice, this turns alerts from a burden into intelligence.

FAQ

Self-hosted Uptime Kuma or SaaS monitoring? If you're monitoring a few key sites and have someone who can maintain a server, self-hosting is enough. If your team needs on-call rotation, SMS/phone, or simply doesn't want to operate the monitoring service itself, SaaS is more convenient.

Is more metrics always better? No. Too many metrics is the same as no metrics. Keep the three main lines — availability, response time, error rate — and add one or two core business metrics.

Why insist on external probing? A self-test on the same host bypasses the datacenter network, DNS, and the public path, so results are "optimistically" good and don't represent real user reachability.

Reference: Uptime Kuma docs — https://github.com/louislam/uptime-kuma ; Prometheus docs — https://prometheus.io/docs/introduction/overview/