Every anomaly BetterDB catches
No manual thresholds to configure. BetterDB learns each metric's baseline, correlates related deviations into named patterns with a diagnosis and recommended actions - and runs state-change guards for the cluster failures a statistical model can never see.
Baselines, not thresholds
Every monitored metric gets a rolling statistical baseline. Spikes and drops are measured against what is normal for your instance, so a busy cache and a quiet one both get accurate alerts.
Correlation and diagnosis
Related deviations are grouped into one event and matched to a named pattern - so instead of four separate metric alerts you get “batch job” with the client responsible and what to do about it.
State-change guards
Failovers, split-brain, wiped replicas, and stalled persistence are not statistical outliers - they are state transitions. Dedicated detectors track them across polls, built against real upstream Valkey failure reports.
Workload & traffic patterns
Correlated statistical detection across connections, throughput, memory, evictions, slowlog rate, and ACL denials.
Traffic burst
Trigger: Connections and ops/sec spike together without a memory spike, or network in/out throughput spikes.
A legitimate surge - a feature launch, viral traffic, a retry storm from an upstream service, or a recurring daily peak. Distinguished from a batch job by the absence of memory growth.
Batch job
Trigger: Connections, ops/sec, and memory all spike at the same time.
A bulk import, backup, migration script, or scheduled processing job is running. BetterDB identifies the client responsible so you can move it off-peak or rate-limit it.
Connection leak
Trigger: Connections climb without a matching rise in ops/sec.
Connections are accumulating without traffic to justify them - a connection pool leak, clients not closing connections, or idle connections piling up faster than cleanup.
Cache thrashing
Trigger: Keyspace misses and evicted keys spike together.
Keys are being evicted and immediately requested again - the working set no longer fits in memory, or the eviction policy is wrong for the workload.
Memory pressure
Trigger: Memory usage spikes, optionally alongside evictions or rising fragmentation.
A large import, a leak, or keys landing without TTLs. Caught before it becomes an eviction storm or an OOM.
Slow queries
Trigger: The rate of new slowlog entries jumps, or clients start blocking.
Operations on oversized data structures, blocking commands, or inefficient patterns. Tracked via the monotonic slowlog ID - not SLOWLOG LEN, which saturates at slowlog-max-len and goes blind exactly when things get bad.
Auth attack
Trigger: ACL denials spike.
A brute-force attempt, misconfigured credentials, or expired ACL permissions. Cross-referenced with the audit trail to show which clients and users are behind the denials.
Unknown
Trigger: A metric deviates from its baseline but matches no known pattern.
Honest signaling: you still get the alert with the raw metric evidence, without a guessed diagnosis attached.
Cluster & replication safety guards
Built against failure modes reported in the Valkey project itself - the issue numbers are right there. If your cluster can enter the state, BetterDB alerts on it.
Node failover
Trigger: A node transitions from primary to replica between polls.
A Sentinel or cluster failover, a manual FAILOVER, or a network partition changed who is primary - one of the most operationally significant events there is. Fires CRITICAL immediately.
Split-brain / duplicate primary
valkey#2261Trigger: Two live primaries claim the same hash-slot range.
The cluster has entered an invalid topology: one shard, two primaries. BetterDB identifies the phantom primary (the one with the lower config epoch) - the exact node that must be demoted. Failover-aware, so a healthy promotion never trips it.
Stuck replica
valkey#2090Trigger: A replica keeps replicating a primary that is dead or gone from the cluster view, persisting across multiple polls.
After a primary is replaced (a Kubernetes pod restart, for instance), a surviving replica can keep pointing at the old node ID forever. Without operator action it never recovers - BetterDB tells you which replica to re-point and where.
Data-loss guard
valkey#579Trigger: A primary comes back with zero keys after holding data (with restart evidence, so a deliberate FLUSHALL does not fire it) - or a replica’s dataset collapses after a full resync.
The nightmare scenario: an empty restarted primary wipes its replicas via full resync. BetterDB fires CRITICAL on the primary the moment it returns empty - while replicas still hold data - and tells you to detach them before they resync.
Capacity, persistence & upgrade guards
Persistence stall
Trigger: A BGSAVE or AOF-rewrite fork child freezes its key progress, exceeds a time ceiling, or its last-status flips from ok to err.
A wedged persistence child can silently block writes, balloon memory through copy-on-write, and leave you without a recent backup. Progress-frozen saves fire CRITICAL after 60 seconds by default; every threshold is configurable.
Connection saturation
Trigger: Connected clients approach maxclients - WARNING at 80%, CRITICAL at 95% - or the server starts rejecting connections outright.
You hear about maxclients before applications start failing to connect, not after. Hysteresis ensures you are alerted on escalation, not spammed on every poll.
P99 latency regression
Trigger: After a server version change, any frequently-called command holds at 1.5× its pre-upgrade P99 baseline. Outside upgrades, a sustained 2× degradation against the rolling 24-hour baseline.
The upgrade guard (built against valkey#3527): update Valkey, and BetterDB watches a 24-hour window comparing per-command P99 against the version you left. Correlates with cluster topology-refresh bursts to catch the hourly-spike signature.
Where the alerts go
Every anomaly is delivered as a webhook event, to Slack or email, and exposed as Prometheus metrics for your existing Alertmanager setup. Severity is graded INFO / WARNING / CRITICAL per pattern. And when an anomaly needs raw evidence, one click arms a MONITOR capture that starts recording the moment the anomaly fires again.
Anomaly detection and diagnosis is part of the Pro tier - free during early access.
Stop finding out from your users
BetterDB learns what normal looks like for your Valkey or Redis and tells you the moment it isn't - with a diagnosis, not just a graph. Self-host via Docker or npx, or use our cloud.