All resources
Monitoring2026-08-01 · 5 min read

What Real-Time Database Monitoring Should Actually Measure

CPU and RAM are table stakes. The signals that predict an outage are connection saturation, replication lag and p95 query latency.

Vanity metrics vs. leading indicators

A dashboard full of green CPU gauges tells you almost nothing about whether the next deploy will take the database down. CPU is a lagging indicator: by the time it saturates, queries have already been queuing for a while.

The leading indicators are connection pool utilisation, lock wait time, replication lag and the p95 of query latency. Each of them starts drifting minutes to hours before users notice anything.

Sampling frequency matters

A one-minute sample interval hides a 20-second stall completely. SaveMyDB's agent streams metrics every second and keeps the full resolution, so a spike is a spike rather than a rounding error in an average.

Alert on symptoms, not thresholds

Static thresholds either fire constantly or never. Pair them with rate-of-change rules: disk usage crossing 80% is worth knowing, but disk usage climbing 4% an hour is what actually gets someone out of bed in time.

savemydb

Back up, monitor and restore every database for $1 each per month

Get Started Now