Website Monitoring Guide

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.

Uptime Kuma Deployment

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

Alert Channels Priority

  1. Email — baseline notifications for all team
  2. Telegram/Slack — real-time alerts for on-call
  3. SMS — critical failures only
  4. Phone — P0 incidents


## Monitoring Reveals What You Don't Know

Simple question: is your site online right now? Most people can answer. Next question: 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.

## Three Non-Negotiable Metrics

### Availability

The most basic metric: is your site returning 200 OK?

Every 1-5 minutes, send an HTTP request from an external source and check the response code. If three consecutive checks fail, trigger an alert.

### Response Time

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

General reference:

| Page Type | P95 Threshold |
|-----------|---------------|
| Static | < 800ms |
| Dynamic | < 2s |
| API | < 500ms |

### Error Rate

HTTP 5xx errors won't hit zero — but sustained rates above 0.5% warrant investigation. A jump from 0.1% to 5% might be 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 ensure important alerts 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 start becoming numb to alerts. Alert fatigue is more dangerous than having no alerts at all.

## Recommended Open-Source Stack

| Function | Tool | Setup Difficulty |
|----------|------|-----------------|
| Uptime monitoring | Uptime Kuma | Low (5-min Docker deploy) |
| Performance metrics | Prometheus + Grafana | Medium |
| Log aggregation | Loki or ELK | Medium-high |
| Alert notification | Alertmanager | Medium |

For small to medium sites, start with Uptime Kuma and Grafana. Don't deploy the full ELK stack on day one.

## Final Note

The biggest enemy of effective monitoring isn't technical complexity — it's alert overload. Fewer alerts, better alerts. One clean dashboard is worth more than a hundred ignored red indicators.