Ownership is answerable. Attention isn't. Here's the gap between the two — and why hiring someone doesn't close it.
Key takeaways:
There's a question that gets asked in almost every database incident review, usually somewhere around the second hour: who owns this?
And it's a bad question — because it's answerable. Somebody's name is in the service catalog. Somebody's team is listed against the instance in the CMDB. The org chart has a line for it.
The question that actually explains the incident is the harder one. Not who owns it. When did anyone last look at it?
The DBA who originally set the instance up left in 2022. Their work was absorbed by the platform team, who already had a queue. The application team treats the database as the platform team's problem. The platform team treats the underlying engine as the vendor's problem. The vendor handles patches, but not performance. And performance is handled by whoever happens to notice it's slow.
Nominally, ownership survived all of that. Somebody is still accountable on paper. What didn't survive is the routine of someone actually opening the thing up and checking on it.
None of this is deliberate. It's the predictable outcome of a model that's been stretched past its design point:
Ten years ago, "the DBA" knew every instance by name. Today, the people accountable for the estate often can't tell you, without checking, how many instances there are.
The thing about a database nobody is looking at is that it doesn't fail loudly. It drifts.
None of these are incidents on their own. They're the conditions under which an incident becomes inevitable. And every one of them would have been caught by someone simply looking — asking "did the backup actually finish?" and "is this index still doing anything?" and "should this service account still have write access?"
Some teams genuinely do have this covered: a named DBA, a real review cadence, a maintenance calendar that gets honoured even in a bad week. If that's you, most of this doesn't apply. It's also, in our experience, a minority position — and one that usually rests on a single person who hasn't left yet.
The obvious response to all this is headcount. If nobody's watching, hire somebody to watch.
It's a reasonable instinct, and it helps. But it doesn't close the gap, because the problem isn't that the work is difficult. It's that the work is continuous, voluminous, and easy to defer.
A person reviewing forty instances can look at each one properly perhaps once a month. Drift doesn't respect that interval. And the moment there's a live incident — which there always is — the review work is the first thing to slip, because nothing bad happens today if you skip it. That's the whole trap: deferring attention has no immediate cost, right up until it has a very large one.
Which means the constraint isn't how many people you have. It's that continuous attention across a large estate is not something humans are built to sustain, however competent or well-intentioned they are.
The practical move is to stop making attention depend on someone being free to give it.
That means the unglamorous work — permission reviews, job checks, configuration drift, capacity creep — running at the cadence of the system rather than the cadence of human availability. Not to replace the DBA, but to hand them a shortlist instead of a search.
Done well, this changes the question. It stops being who owns this? — because ownership was never really the problem. It becomes what's drifting, and what should we do about it? That's a question you can actually act on.
This is what DB24 is built around. Continuous, automated monitoring across your entire SQL Server estate — so attention doesn't depend on anyone being free, the drift gets caught, and the small questions get answered before they grow into incidents.