🌐 Website Status Monitor

ℹ️ About This Monitor

A real-time website monitoring dashboard that tracks the availability, response time, and uptime of multiple websites across different business groups. When a site goes down, email alerts are automatically sent to the designated group contact.

🛠️ Tech Stack

⚙️ How It Works

• 🔍 Health Check: Cron worker checks each site individually in parallel via /api/check?url=X. Each check takes two samples and reads the full response body, recording TTFB, total time, bytes received versus advertised, throughput, and — if it failed — which phase failed (dns / connect / tls / http / body / timeout).
• 📦 Why the body matters: A check that only awaits fetch() is measuring time-to-first-byte and trusting the status line — so a site returning 200 OK and then never finishing its body scores as healthy. That is exactly the failure mode that a headers-only monitor misses.
• 🧪 Asset Probe: Optionally, a small file on the same host is measured alongside the page. A 4 KB file that answers in ~0.16 s while the homepage needs ~1.5 s means the CMS is slow, not the network.
• 🔎 External Vantages: Every 15 minutes, probes from Hong Kong, Singapore and mainland China measure each site from outside Cloudflare, plus a direct origin-IP probe that bypasses Cloudflare entirely to see the edge→origin leg. The China vantages are residential ISPs — China Unicom, China Mobile and China Telecom — not cloud hosts, because those route internationally very differently from one another. A fault that appears on some cities but not others is a transit fault; one that appears everywhere is the origin.
• 📊 Dashboard: The dashboard reads the latest stored results via /api/latest, so what you see is what the alerting acted on. "Check Now" runs a live read-only batch check on demand.
• 💾 D1 Logging: Every cron result is stored in status_log; external probes go to probe_log. Records older than 30 days are automatically purged.
• 🔔 Alert Routing: Two alert types, each rate-limited to once per URL per hour: down (did not answer, or the body never completed) and degraded (answered, but slowly, intermittently, or short of bytes). Down takes precedence. Dedup is atomic to prevent duplicate alerts.
• 📧 Daily Summary: At 9AM HKT, a summary email with fleet p95 TTFB and per-site p50/p95 goes to all recipients.
• 🛡️ Admin Panel: Add, edit, or remove monitored sites, and set per-site thresholds and probes, through the admin panel (password protected).
• 🌐 WAF Integration: Cloudflare zones are configured with WAF skip rules (including SBFM + managed rules) to allow monitoring traffic through challenge pages. The bypass header is sent only to sites whose waf_bypass flag is set, never to third-party URLs.
• 🔒 Security: Cron endpoints require a shared secret; external ingest requires a bearer token. Security headers on all responses. Chart.js loaded with SRI integrity check.

🗄️ Database Schema

• 📋 monitored_sites — URL, group, alert email, enabled flag, per-site thresholds and probes
• 📊 status_log — Timestamp, URL, group, HTTP status, ok flag, plus TTFB, total, bytes, throughput, sample counts, fail phase, cache status and edge colo
• 🔎 probe_log — External vantage results: DNS / TCP / TLS / TTFB / download timings per location
• 🗺️ probes — Registry of measurement vantages
• 📧 alerts_sent — URL, alert type (down or degraded), timestamp, message

📬 Alert Recipients

Each group has a designated alert email configured via the Admin Panel. Alert emails are rate-limited to 1 per URL per hour to prevent spam.

All degradation thresholds default to off (0) and are set per site in Admin → Monitoring options. External vantages need an origin_ip to probe the edge→origin leg, and an asset URL to separate CMS slowness from network slowness.