What shipped in July: offline licensing, native OpenTelemetry, and fifteen new detectors

July was a detection month.

The through-line, if there is one: we spent it teaching Monitor to catch the failures that don't announce themselves - the silent, non-self-healing conditions that only surface as a symptom hours later. Fifteen new anomaly detectors shipped across the month, each one built from a real thread on the Valkey issue tracker.

But the single biggest thing landed somewhere else, so I'll lead with it.

Air-gapped licensing

You can now run BetterDB Pro and Enterprise fully offline, with zero outbound network. If you operate in an air-gapped or regulated environment, that's the whole ballgame - it's the difference between "compliant" and "get this off my segment."

Download a signed offline token from your account page, activate it in the UI or by config (BETTERDB_OFFLINE_LICENSE), and the monitor verifies it locally against public keys baked into the image. No phone-home. The verification is a standard RS256 signature check, so a spoofed or compromised entitlement endpoint can't grant a tier either - it's math, not a server you have to trust. And when the monitor runs purely from an offline token, it turns telemetry and phone-home off automatically, enforced at the earliest point in startup.

Your most sensitive databases deserve better monitoring than your public-facing ones, not none. I wrote up why it matters, how we built it, and the honest trade-offs in a dedicated post: No Internet Required: Air-Gapped Monitoring for Valkey and Redis.

OpenTelemetry, properly

If you already run an OTel collector, Monitor now fits in natively instead of asking you to bolt on a webhook.

OTLP traces, a waterfall view, and Valkey correlation, plus a Valkey-native AI Cache & Memory tab - so an inference trace lines up against what the database was doing underneath it.
Unit metadata. The exporter derives UCUM units from metric-name suffixes (_bytes → By, _seconds → s) without renaming your metrics.
Monitor now ingests and dispatches OTLP, so it drops into your pipeline at either end: pull your app's traces in to line up against the database, or push Valkey signals out to the collector you already run.

One consequence worth calling out: anomaly dispatch and instance.up/instance.down availability edges are now decoupled from the Pro webhook gate, so an OTLP-only deployment gets complete telemetry, not a subset.

More of Monitor, over MCP

The MCP surface isn't new, but it grew this month. Three more sets of tools land in @betterdb/mcp 1.4.0, on top of the existing cache-intelligence and health tooling:

AI observability - query cache and memory behavior directly.
Analytics - hot keys, big keys, slowlog and commandlog patterns, on demand.
Vector search - inspect vector indexes, doc counts, and indexing state.

So the coding agent you already use to debug your database, along with the self-tuning cache loop, can now read your instance's health, pull the anomalies, and reason about your keyspace and vector indexes - without you screenshotting a dashboard into a prompt.

Fifteen new anomaly detectors, from the Valkey issue tracker

Most incidents don't start as a spike on a graph you're watching. They start silent and surface late. So we worked the tracker top to bottom and built a detector for each failure mode. Every one below links to its upstream thread, auto-resolves when the condition clears, and emits over the existing webhook, OTLP, and dashboard channels - no new wiring.

Cluster and replication

Split-brain. Flags a hash-slot range claimed by more than one primary and names the phantom. CRITICAL, re-arms when it clears. valkey#2261
Empty-primary full-resync data-loss guard. Catches a persistence-less primary restarting empty before replicas resync onto the void. Adds a data.loss.detected webhook. valkey#579
Orphaned replicas after primary loss. A replica that never re-attaches and quietly serves stale reads. valkey#2090
Replicas stuck migrating/importing. After a reshard, replicas keep reporting slots as migrating until an operator runs CLUSTER SETSLOT … STABLE. valkey#1664
Gossip-mode failover churn. A single shard re-electing repeatedly, the signature of competing FAILOVER coordinators. valkey#3996
Replication output-buffer pressure. Per-replica alerts with early warning, before the buffer blows and forces a full resync. valkey#3963
Control-plane saturation. Sustained high CPU paired with control-plane impact, so "busy" reads differently from "too busy to stay in the cluster." valkey#3927
Cluster V2 (Raft) health detection, with gossip-mode gating so the right checks run on the right topology.
Connection saturation, with rejected_connections unbundled so refusals are counted distinctly. valkey#3918

Memory, load, and persistence

Non-dataset memory overhead. Buffers, backlog, and cluster-bus links draw on the same maxmemory budget and quietly evict real data. Names the culprit and the fix. valkey#1792
Event-loop load saturation. On a single-threaded server raw CPU% lies. Measures real event-loop busy time and points at slow O(N) commands instead of "add more CPU." valkey#2055
Fork / copy-on-write OOM risk. A save that dirties enough COW pages can push RSS into OOM-killer territory mid-fork. Catches a live save trending toward the limit and a write rate that makes the next fork risky. valkey#3609
Stalled BGSAVE / AOF forks. Fires when a fork child freezes, overruns, or flips last-save status to err. Clears when it exits. valkey#2322
Client-eviction storms. When Valkey evicts clients to reclaim maxmemory-clients memory. Previously silent. valkey#4151

Latency and config hazards

P99 latency-regression guard for upgrades. Opens a 24h window on a version change and fires if a command's P99 stays at 1.5x its baseline or worse. Adds a latency.regression.detected webhook. valkey#3527
Config-hazard advisory. A default user disabled together with AOF can silently lose writes on reload. Flagged before it bites. valkey#3983
ACL deny-wins fix. A default user with +@all then denials was read as a safe, unrestricted grant. Now any deny token defeats the unrestricted claim.

The caching and memory SDKs kept moving

Detection wasn't the only thing shipping. Across the month:

agent-cache: cache streaming LLM responses via wrapStream. New OpenAI Agents SDK adapter (TypeScript) and Pydantic AI adapter (Python).
semantic-cache: new Google AI (Gemini) embedding provider. Runtime-configurable default TTL via a __config hash, so you change TTL with no redeploy.
agent-memory: opt-in write-time fact consolidation, merged consolidate() modes, surfaced unmatched tombstones, and tuned recall. (If you want the deeper story on why memory correctness is a data problem, not a reasoning one, that's its own post.)
retrieval: structured context assembly, a query-time temporal resolver, and a LongMemEval lever-ablation harness with question-type stratification - so recall levers get measured, not guessed.

Also shipped

Composite hot/big-key detection. Surfaces the key that's extreme on more than one dimension at once - the large collection that's also getting hammered. New GET /key-analytics/composite-keys.
SCAN large-reply hash-skew advisory. Flags SCAN-family commands returning disproportionate bytes per element.
Bulk delete-by-pattern. A client-side SCAN + UNLINK walk with dry-run preview, pacing, cooperative cancel, and cluster fan-out. A catch-all * requires explicit confirmation. valkey#2623
Top-N worst-offenders sort for the slow and command logs.
Redesigned first-run screen, to make that initial connection as easy as possible.

Migrating off KeyDB and older Redis, cleanly

To close where the month opened - on the adoption side. Migration analysis used to probe the source with a multi-section INFO call that only Valkey and Redis 7+ understand, which broke against older engines. It now issues one INFO per section, so migrating off KeyDB or Redis 6 works without hand-holding. If you're consolidating a mixed fleet onto Valkey, this is the on-ramp.

That's the month - a lot of it invisible until the day it saves you. As always, if something's broken, missing, or you want a hand with a migration, email me directly at kristiyan@betterdb.com. I read every one.