Database reliability is not uptime

The uptime illusion

Most monitoring starts with one question: is it up? It is a fair first question. It is also the one a database almost always answers yes to, right up until the morning someone asks why checkout got slow two weeks ago, why the nightly job now runs into business hours, or why an auditor found a server on a version that stopped getting security fixes last year.

None of those were outages. All of them were reliability failures. The database was up the whole time.

Five kinds of signals

1. Queries getting slower

Not slow: slower. A query that has always taken 300 ms is not news. One that took 38 ms last week and takes 54 ms now is, even though no fixed threshold would ever catch it. The useful comparison is each query against its own history, at the same time of day.

2. The workload changing shape

The read and write mix shifts, rollbacks climb, connections pile up in idle transactions, the cache hit ratio slides. Each change is small and has an innocent explanation. Together they are often the first sign of a release that changed how the application uses the database.

3. Monitoring that has gone quiet

The most dangerous chart is the empty one that looks calm. If an agent stops sending data, every graph goes flat and every alert goes silent, and that looks exactly like a healthy database. Silence should raise an alert of its own.

4. Version and security exposure

Engine versions reach end of life on a published schedule, and vulnerabilities are published against version ranges. Settings drift: a superuser role nobody remembers granting, an extended stored procedure turned on for a one-off task. None of this shows up in performance graphs, and all of it shows up in an audit.

5. Schema and permission drift

An index dropped in a cleanup, a column added outside the migration tool, a grant to a reporting role that was meant to be temporary. Knowing what changed, and when, turns a long investigation into a short one.

A scale problem, not a skill problem

A team of three DBAs can watch ten databases by hand. They cannot watch three hundred, across PostgreSQL, SQL Server, Oracle, MongoDB and the Redis in front of all of them, each with its own console and its own ways to fail. At that scale, reliability depends on the system telling people where to look, with the evidence attached, instead of people looking everywhere.

The people who are not on call

Reliability also has readers who will never open a monitoring tool: the CTO deciding where to spend, the security lead preparing for an audit, the auditor. They need a document: which servers are past end of life, what the exposure is, what the plan is and how much work it takes.

A checklist to start with

For each production database, can you answer these today?

1. Which of its queries are slower than they were a week ago, at the same time of day?
2. Has its workload changed shape since the last release?
3. Would you know within a day if monitoring stopped receiving its data?
4. Is its version still supported, and which known vulnerabilities apply to it?
5. What changed in its schema and permissions this month?
6. Could you hand a one-page summary of the above to someone who will never log in?

Every "no" is a gap in reliability, whatever the uptime figure says. This is the list Logstag is built around: Insights for the first two, alerts for the third, the Security Report for the fourth, the schema explorer for the fifth and reports for the last.