Skip to main content

Monitoring Foundation

Monitoring is how you keep performance improvements from drifting. The goal is not to stare at dashboards; it is to detect regressions early and have enough context to troubleshoot quickly.

Core Idea

Monitor four layers: user experience, edge/cache behavior, application/DB behavior, and origin health.

What to Monitor

LayerSignalsTypical tools
User experienceCWV trends, slow paths by deviceCloudflare RUM, Search Console (CrUX)
Edge/cachecache status shifts, 4xx/5xx spikes, threat spikesCloudflare Analytics, Security Events
App/DBslow queries, error rates, top slow routesslow query log, APM (optional), Query Monitor (staging)
OriginCPU/RAM/disk pressure, worker saturationNetdata, provider graphs

Alerting Principles

  • Alert on changes that matter: 5xx spikes, sustained latency increases, resource exhaustion.
  • Prefer "change detection" over rigid thresholds (baseline first, then alert on deviations).
  • Reduce noise: multi-region confirmation, short retry windows, and clear severity routing.

Monitoring Workflow

Time: 2 minutes

  1. Check Cloudflare for errors (5xx) and cache status shifts.
  2. If anything looks off, check the origin for resource pressure.

Common Mistakes

MistakeWhat HappensHow to Fix
Only using lab tests (Lighthouse)Miss real-user performance issuesAdd field data monitoring (Search Console)
No server-level monitoringDiscover resource exhaustion from user complaintsInstall Netdata or similar
Dashboards but no alertsRegressions go unnoticed for daysConfigure threshold-based alerts
Ignoring database monitoringSlow queries silently degrade performanceMonitor slow query log

Checklist

View Checklist
  • Server monitoring tool is installed and accessible.
  • Core Web Vitals are tracked in Google Search Console.
  • Query Monitor is installed on staging/development.
  • Uptime monitoring is configured with alerts.
  • Alert thresholds are defined for CPU, RAM, disk, and error rate.
  • Recurring performance review is scheduled.

What's Next