Valkey anomaly detection
How does anomaly detection actually work for Valkey and Redis? This page explains the mechanics - baseline learning, Z-scores, correlation, and diagnosis - and where static thresholds fall short.
What static thresholds miss
Traditional monitoring alerts when a metric crosses a fixed line ("memory > 80%"). Four failure modes show up in practice:
Gradual degradation
A slow memory leak stays under "alert if memory > 80%" for weeks - until it doesn't, at 3am.
Unusual-for-you patterns
A jump from 250 to 400 connections is an incident for one deployment and a Tuesday for another. Static thresholds can't know which.
Correlated issues
Memory, evictions, and keyspace misses each move a little - individually below any threshold, together a clear cache-thrashing signature.
Attack patterns
A spike in AUTH failures or ACL denials is only meaningful relative to your normal rate.
How baseline-based detection works
1. Baseline learning
Each monitored metric keeps a rolling window of recent samples (polled every second) and continuously computes its mean and standard deviation. Your instance defines "normal" - no configuration required.
2. Z-score analysis
Every new sample is scored by how many standard deviations it sits from the baseline mean. Sustained deviations (multiple consecutive samples, with cooldowns) become anomaly events - which keeps false positives low.
3. Correlation
Anomalies that fire close together in time are grouped. Connections + ops/sec + memory spiking together is a different situation than connections spiking alone.
4. Diagnosis
Each correlated group is matched against known operational signatures - batch job, connection leak, cache thrashing, traffic burst, memory pressure, auth attack, failover, persistence stall - and reported in plain English with recommended next steps.
Metrics watched out of the box
How BetterDB implements it
BetterDB ships 20+ detectors with automatic baseline learning - statistical detectors for workload patterns, plus state-change detectors for cluster safety conditions (split-brain, stuck replicas, failovers) that a Z-score can never see. Every diagnosed pattern names the likely cause, identifies the responsible client where possible, and is exported as Prometheus metrics for your existing alerting. Anomaly detection is a Pro feature, free during early access.
Browse the full catalog of detected patterns →FAQ
What is anomaly detection for Valkey?
Anomaly detection for Valkey is the automatic identification of abnormal database behavior - connection leaks, cache thrashing, memory pressure, auth attacks, failovers - by learning the baseline behavior of your specific instance and flagging statistically significant deviations, instead of relying on hand-set static thresholds.
Why not just set alert thresholds in Prometheus?
Static thresholds fail in four common ways: gradual degradation that never crosses the line, values that are abnormal for your workload but normal in general, correlated multi-metric issues where no single metric breaches, and rate-based patterns like auth attacks. Baseline-relative detection catches all four. The approaches also compose: BetterDB exports anomaly state as Prometheus metrics, so your existing Alertmanager can alert on diagnosed patterns.
How does BetterDB avoid false positives?
Three mechanisms: a warmup period before any alerting (baselines need enough samples), a requirement for multiple consecutive anomalous samples before an event fires, and per-metric cooldown periods between alerts. Severity is graded - roughly two standard deviations is a warning, three is critical.
Which anomaly patterns does BetterDB detect?
Detected patterns include traffic bursts, batch jobs, connection leaks, cache thrashing, memory pressure, auth attacks, node failover, persistence stalls, and P99 latency regressions, among 20+ detectors - including state-change detectors for cluster safety conditions that statistical analysis alone cannot see.
Is anomaly detection free?
Anomaly detection is a Pro feature of BetterDB, currently free during early access. The core monitor is open source (MIT).
Let it learn your baseline
Start it against a dev instance - detection warms up in minutes.
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.