Monitoring tells you what. Diagnosis tells you why.

Here’s a test you can run on your own incident history. Take your last five database incidents and ask, for each: at the moment the first alert fired, how long until someone could state the root cause with confidence?

If your answers cluster around “two to four hours,” you’re normal. That number has barely moved in a decade — a decade in which monitoring got spectacularly better. Prettier dashboards, richer traces, higher-cardinality metrics, anomaly detection on everything. And the investigation gap sits exactly where it was, because the industry has been improving the what while the why remained artisanal.

Why the gap persists

Monitoring vendors will tell you the why is in the dashboards — you just have to correlate it. That word “just” carries the entire cost structure of database operations.

Correlation across forty dashboards is a skill. It lives in the heads of your most senior people, it doesn’t scale past their attention, and it’s exercised at the worst possible times. The knowledge itself is real: a veteran PostgreSQL DBA seeing p99 climb knows the trail — check for plan flips, check vacuum health, check lock chains, check replication — and walks it in a fixed, evidence-driven order. That’s not intuition. That’s a procedure that happens to be stored in a human.

Procedures stored in humans can be encoded

That sentence is the entire thesis of dbexpertAI.

We call the encoded version a detection path: the expert’s investigation trail, written down, curated, and executed autonomously against your live database every 90 seconds. When the evidence confirms a problem, what you receive is not an alert — it’s the concluded investigation: root cause, the diagnostic evidence behind it, and concrete resolution steps.

Three properties make this work where “AI insights” products haven’t:

Deterministic. Same evidence, same diagnosis, every run. No model temperature, no probabilistic guessing on production systems. When the diagnosis says autovacuum starved on orders, it’s because the dead-tuple ratio, the vacuum timestamps, and the cost-limit saturation all said so — and they’re in the report.

Engine-idiomatic. PostgreSQL fails like PostgreSQL (bloat, plan flips, idle-in-transaction locks). Galera fails like Galera (flow control, certification conflicts). SQL Server fails like SQL Server (parameter sniffing, tempdb allocation contention). Generic monitoring flattens these into CPU and latency; detection paths investigate each engine the way its own experts do — across all five SQL systems we cover.

Autonomous. The 90-second cadence means the investigation usually finishes before a human would have opened the first dashboard. The 3am page becomes optional reading of a concluded report instead of the start of a manual shift.

What this doesn’t replace

Keep your monitoring. Sincerely — dashboards are the right tool for capacity planning, trend analysis, and the situational awareness that keeps engineers oriented. Grafana, Datadog, PMM: all good at what they are.

The layer they were never built to fill is the one between the symptom and the fix. That layer has been staffed by senior engineers doing 2–4 hour investigations, one incident at a time, forever. It’s the most expensive, least leveraged work in database operations — and it’s the most encodable, because the investigations are procedures.

Monitoring tells you what. Diagnosis tells you why. The why is now a deliverable.