It’s Still Not Your Emergency

A message hit our Teams “Lounge” channel where we talk about anything in life, sometimes work. One of our DBAs was worried about a client’s data – some rows that didn’t look the way they should look with a likely data issue, and a growing question about how far back the problem went hit her.

You could feel the worry in the message. That’s not a criticism. That’s a great DBA caring about a client, it’s our Ownership Mentality value on full display, living into our “See something…. Do something….” principle. It’s the exact instinct you want in someone who’s responsible for other people’s data.

I sent her a link to something I wrote in December of 2020, called It’s Not Your Emergency!. I was working through my EMT licenses again (later to abandon that mission – it was really time to let the license stay lapsed, Straight Path was getting busier and the pandemic rules and processes wasn’t making it worth it, plus the town was increasing the full-time count), I’d written up something I learned on an ambulance long before I ever saved a corrupt database or AG destroyed by Sentinel One: the more distance you can put between yourself and the emergency, the better you will perform inside it.

Six years later, I still believe every word of it… Six years later, I’m still far better at living every word of it at work in real emergencies and forget it when something mildly annoying or out of sequence happens in my personal life.. Work in progress... A few things have changed enough that the post needs an update and one of them has made the whole problem considerably worse. Plus it’s a good time for a reminder.

The Core That Hasn’t Changed

The core idea is the same as it was on my first ambulance call in 2005 or any war room I was on in 2020 (your average ambulance call and your average warm room call really haven’t changed that much.. Actually maybe the ambulance calls have changed more…. Stretchers that lift for you and LUCAS CPR devices, meanwhile it’s still SQL Server 2016 half the time and the same self owns far too often on the work side…)

But like Bob Seger sang… Still the same… You get pulled into the emotion of an outage. Your stress rises. Tunnel vision sets in , and you skip past the boring simple explanation because surely a problem that has you this worked up can’t be simple. Then panic. Then you do something that makes it worse…

I’ve walked into environments where somebody dropped a database without verifying a recent backup. Detached a corrupt database that could have been fixed if it wasn’t dropped. Took an instance that had a path back and closed that path off permanently. None of those people were incompetent. All of them had made it their emergency.

Naming it out loud…. “this is not my emergency” …. is not about caring less. I’ll come back to that in a bit, because it’s a common misreading of the original post.

What’s New in 2026?

AI is the new panic button

This is the big one, and it didn’t exist in 2020.

The 2020 version of the panic move was restarting a server that was stuck in RECOVERING, which forces SQL Server to start the entire transaction log recovery over from scratch and actively lengthens your outage (except for the times where you actually need to do that because the recovery at restart is faster – but the point is the restart without knowing why…). The 2026 version is pasting an error message into a chat window at 2:14 AM and running whatever comes back.

The answer isn’t to throw out AI. At SP, we use AI tooling every day and it is genuinely useful. But understand what happens at the intersection of the 2AM adrenaline and an answer that seems right when you are knee deep in panic, overthinking “your” emergency and along walks a confident seeming declaration.

• The model does not know your recovery model, your last good backup, your RPO, or whether that database is the one feeding your member facing credit union apps.
• The model’s output sounds calm and authoritative, which is just the thing your anxious brain wants at 2 AM.
• It will happily hand you ALTER DATABASE ... SET EMERGENCY, a DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, or a detach, and it will phrase all three with equal confidence. (That’s if it even gives you something that actually works when you copy and paste it….)

An LLM is a fantastic second opinion when you have distance. It is the wrong drug for the wrong patient at the wrong time when you’re right in the middle of it and shut off your thinking brain. It removes the friction that used to save people – the twenty minutes of reading a Books Online page or a Paul Randal blogpost, during which your pulse came down and you noticed the real problem.

The updated rule: if you would not run it because a stranger on a forum told you to, don’t run it because a model told you to. And never let a generated command be the first thing you execute on a production instance during a crisis, especially. Read it. Explain it out loud to another human (or your cats in the living room at 2AM.) Then decide.

Cloud and PaaS changed the shape of panic, not the existence of it

A lot of our clients are on Azure SQL Database, Managed Instance, or RDS now. On paper that should reduce panic… You have fewer levers to pull, you aren’t the “full DBA” for the full stack, and AWS, Google, or Microsoft are your “co-DBAs”…. so you have fewer ways to make it worse. Right?

In practice it creates a different failure reason. When you can’t get to the box, “in the emergency” turns into one of two bad states: frantically hunting for a knob that doesn’t exist, or freezing entirely because “it’s Microsoft’s problem” while nobody documents anything (and no one documented anything before you got involved since it wasn’t yours anyway….)

Distance on a managed platform means something specific: your job in the first fifteen minutes is evidence collection, not repair (even if the CIO is behind you making all sorts of weird noises). Capture the wait stats, the query store data, the metrics, the exact timestamps, the correlations from the systems you do have access to (oh and check DNS!). That evidence is what gets a platform support ticket escalated in hours instead of days, and it’s what tells you whether this was ever your problem to solve.

Practice for the bad before it happens. Know your fallback, know where your backups off cloud are, know what your manual failover decision points and processes are.

Bad data is not (almost) always an accident anymore

(I mean it never really was, was it?) In 2020, if a client called about data that looked wrong, the differential diagnosis we would run was: a bad deploy, a bad job, an application bug, a bad ETL run, or somebody running an UPDATE without a WHERE clause.

That’s still the top of the list. But the list is longer now, and it includes possibilities where your first instinct (start fixing it) is exactly wrong. If there’s any chance you’re looking at something deliberate, the correct move is to stop touching it, preserve state, and get the right people involved. Distance is what lets you consider that possibility instead of reflexively cleaning it up and destroying the evidence. We live in an age of unprecedented ransomware attacks and any bad vector (like your SQL Server 2016 licenses that you haven’t talked to us about upgrading yet) can and will be exploited. Assume ransomware on the list of first suspects.

The chaos amplifier is now a Teams channel

The cardiac arrest scenes in EMS are loud because there are eight people in a crowded living room, some there with us being helpful, some family, maybe a cop or two (they are often helpful, for the record – and they usually got there before us in an all volunteer town.), and the victim with spotty patient history. It’s chaos. Every serious call is a chaotic scene to start. The modern equivalent is a bridge call with fourteen people on it, a Teams thread, an exec asking for an ETA every four minutes, and a status page nobody’s updating.

The distance problem is now as much social as it is personal. Which is why the single highest-leverage thing you can do on a serious incident is split the roles: one person works the problem, one person owns communication and the clock. We wrote that into how we run P1s years ago and it’s the practice I’d keep if I could only keep one. In a code in the hospital, ACLS dictates that one person be the “note taker/charter/caller” – we don’t really get that luxury in the ambulance – you might have two providers show up, maybe an extra one or two (more now with most fire departments running ambulance so all certified) but we didn’t always have those roles. On your emergencies? You absolutely can. Someone (one person) should drive communication, should do notifications, should record what was done and be off the keyboard and mouse on the connection to ask the “have you tried this?” questions at the right time.

You often know before the client does

Good monitoring changes the emotional starting position of the entire incident. There’s a real difference between picking up the phone to an angry client and calling a client to say “we saw this eleven minutes ago, here’s what we know, here’s what we’re doing.” The second conversation starts with distance already built in. It’s why I’m happy about hiring Richie to join our team as I blogged about last week. It’s why we’ve been working so hard quietly behind the scenes building Skopos and why our roadmap has increasing amounts of proactive and preventative alerting. We love it when we get to tell the client “You have a P1, our team is already in the call working it, please join and let’s explain it and talk options.” It’s 2026, you should have monitoring that make you ahead of the emergency for your own users and customers. I think (hope?) that we’ll continue to see monitoring evolve to help make less surprises for more folks.

The Potential Misread In The Message

I’ve heard a few folks first respond to the “It’s not your emergency” line as “but then you don’t really care?! How is that ownership mentality?”

“It’s not your emergency” is not “I don’t care.”

It is the opposite. It’s a discipline you adopt because you care about the outcome and you’ve noticed that caring “too much – to the point of anxiety makes you worse at producing the outcome you hoped to achieve. The medic who stays clinical is not colder than the one who panics. They’re the one who remembers to check the airway or put the car in park before we take the patient out (or at least chock the wheels…) In EVERY.SINGLE.TEST we took in EMS we would rehearse a mantra to ourselves – “Scene safe, BSI” – we don’t go in ( well… there are exceptions SOPs be darned – we all had the things we’d be willing to move first on and be a bit riskier for, but I digress). We put our gear (Body Substance Isolation – BSI/PPE whatever you want to call it) on. We scanned for dangers. We made sure the police secured an active crime scene. We took care of ourselves first. If we’re dead – we’ve not helped the patient, and we’ve made the situation worse for them because now our partners are having to carry our dumb butts out of the situation, too.

When we let the tunnel vision of panic set in – no one gets helped. We fall fail.

In our day jobs –> What you are freeing yourself from is the burden of responsibility for the exact outcome…. the story your brain is telling you about what this means for your career, your reputation, your standing with this client. What you are absolutely not freeing yourself from is the responsibility to do your best work, at speed, until it’s resolved. In leadership circles, a saying that actually helps is “We’re responsible TO our team, not FOR them.” Same applies for the outage, I guess.

How This Connects to Our Managed DBA Services

Distance is structural first. Then that leads the emotion. The rules and structure enforce it before it becomes nature (and, in some respects, it will always fight nature, so we structure around that.) And a lone internal DBA (or worse, a lone Accidental DBA who is the one stuck on call because they were volunteered because they know how to spell SQL) is a almost prevented from having any distance.

It’s their server. Their deploy, maybe. Their boss standing behind them. Their job that feels like it’s on the line. Their weekend. There is no amount of breathing exercises that fixes a situation where the person troubleshooting is also the person who will be blamed, alone, at 2 AM, with nobody to hand the keyboard to.

That structure is most of what DBA as a Service actually is, underneath the daily reports, health checks, check-in meetings, etc.:

• Two sets of eyes on serious issues. One person in the problem, one person above it watching the clock and the client. This is in the original post from 2020 and it’s SOP here. When a client has a DBA team, that’s more eyes in on it – all on one teams call collaborating. We care deeply but we’re distant. The scene is safe and we’re effective.
• We’ve seen this before. Across our client base, the failure you’re facing for the first time is one we’ve worked through repeatedly in all likelihood. Pattern recognition is distance… It’s the twenty-year medic forming a general impression in four seconds when they walk in the room and tell the probie, “we are taking the patient and leaving, we’ll get vitals on the way to the hospital at code.”
• A checklist instead of heroics. Error logs, disk, backup chain, recent changes, wait stats, etc. We think in steps and checklists and protocols for the scene before us in order every time, before anybody types anything destructive.
• Nobody’s job is on the line in the room (on our side at least). We’re accountable for the outcome and invested in the client. We are not the person who pushed the deploy, even if the absolute worst case happens for a single company, we’re still here. That’s not cold indifference, it’s the distance we need to be most effective. That gap is worth more at 2 AM than any tool.
• Somebody was already watching. Monitoring means the incident usually starts with information rather than with a panicked phone call (ask any first responder how often the scene they show up to is anything like the scene the dispatcher painted based on the 911 call taken… I didn’t track specifics, but it was pretty rare…)

None of that makes an outage pleasant or enjoyable (though we would sometimes want a “good” medical call or “good” accident or fire… We wanted to use our training… Most of us at Straight Path don’t long for the P1s – though a couple thankfully do love them…) It makes it survivable without self-inflicted damage, and it increases the chances of it being solved pretty fast.

If you’re the only person who knows how your SQL Server environment works, you don’t have a tooling problem. You have a distance problem. That’s the one we solve.

Questions to Consider About “Calm” in the Storms of SQL Server Outages…

What should a DBA do first during a production SQL Server outage? Breathe, then gather facts before changing anything. Check the SQL Server error log, verify disk space, confirm the backup chain, and establish what changed most recently. Review the tooling, windows logs and understand the exact nature of the outage. The first fifteen minutes should produce information, not modifications.

Is it safe to run AI-generated recovery commands during a database emergency? Not as a first action. A model has no knowledge of your recovery model, backup history, versions, how you got twisted around, or business impact, and it will suggest destructive operations with the same confidence as safe ones. Use AI as a second opinion after you have established the facts, never as the source of the first command you execute on production. Remember confirmation bias. If you aren’t sure asking “isn’t this dangerous thing the next best step?” will at least 50% of the time give you a confident sounding cheerlead of a bad action.

What does “it’s not your emergency” mean for a DBA? It’s the practice of separating your emotional state from the incident so you can think clearly. It does not mean caring less about the outcome. It means recognizing that a troubleshooter who has internalized the crisis as their own WILL make more mistakes, miss simple explanations, and frequently risk making the problem worse as you speed up trying to get it fixed faster.

How do you build distance if you’re the only DBA at your company? Largely, you can’t build it alone… which is the real argument for an outside team on retainer. In the meantime: timebox your troubleshooting, force yourself to escalate at predefined intervals, and pull in a second person for communication even if they can’t help technically. Bring someone calm and distant to the call and collaborate. Heck, I wasn’t joking about talking to the cat (or Dog, I suppose) – just stating your assessment and plan out loud can help you think about what you are doing. Learn some good breathing exercises and force the issue to go just a fraction of a moment slower than you think it needs to. If the CIO or leadership team wants you gone because of that – then you should update your resume and work somewhere with more cover. You can also reach out to us and get our team of DBAs to be your backup DBA and help you out, you know how to find us.

Can you think of situations where you saw this “not my emergency” at work and it made a difference? Can you think of situations where it would have made a difference? I’d love to read about them in the comments.