--- title: "During an incident, the hardest call is whether to stop everything" url: "https://cooinsider.com/insight/during-an-incident-the-hardest-call-is-whether-to-stop-everything/" author: "Nick Sawinyh" published: "2026-09-21" updated: "2026-09-21" --- # During an incident, the hardest call is whether to stop everything I ran product and communications for a lending protocol that got exploited, twice, during the period I was there. Money was taken, publicly, on a system anyone could inspect in real time. That's an unusually harsh environment for incident response, because the audience is watching the same data you're and forming conclusions faster than you can verify them. The decision that mattered most in both cases, and the one I've thought about most since, was not technical. It was whether to halt. ## The asymmetry nobody prices correctly Halting operations feels enormous. It's visible, it costs money by the minute, customers notice immediately, and somebody will have to justify it afterward. Continuing feels like the neutral option, the one that requires no decision. That framing is wrong and it's the root of most bad calls. Continuing is a decision. It's a bet that the thing you don't yet understand isn't getting worse. You're making that bet either way, so make it explicitly. The asymmetry that actually matters: a halt is reversible and its cost is known within an order of magnitude. Continuing through an active, uncharacterized problem has an unbounded downside. Under uncertainty, you should prefer the bounded loss, and the reason organizations reliably do the opposite is that the cost of halting is attributable to a person while the cost of continuing looks like bad luck. ## The question that resolves it faster Rather than debating whether to halt, I ask one question: **do we know the mechanism?** Not the cause. Not who did it or why. The mechanism, meaning what's the sequence of events by which this is happening, and does our understanding predict what we have observed? If yes, you can usually continue with a targeted mitigation, because you know what you're containing. If no, you are guessing, and every minute of continued operation is exposure of unknown size. I find this more useful than severity scales because it is answerable in minutes and it's hard to argue with. "We think it's probably the payment service" is not knowing the mechanism. "We can explain every failed transaction we have seen, and our explanation predicted the next three" is. The second question, if the first is no: **is this bounded?** Can it get worse on its own while we work? Some incidents are static, a bad state that exists but isn't spreading. Those you can work through. Anything that compounds, financially or in blast radius, is a halt, because your time to understand it is being spent by the incident rather than by you. ## What halting should actually mean Most organizations only have two states, running and off, and that binary is why the decision feels so heavy. The useful version is a set of intermediate stops defined in advance. Stop accepting new work but finish what is in flight. Stop the automated path but keep manual processing. Stop for new customers but not existing ones. Read-only mode. Deciding these during an incident is nearly impossible, because everyone is arguing about severity while the clock runs. Deciding them in advance turns an agonizing judgment into a selection from a menu. If your operation has exactly one lever and it says off, you will hesitate to pull it, and the hesitation will cost more than the halt would have. ## The communication half In both exploits, the thing that preserved trust wasn't the fix. It was saying what we knew, what we didn't know, and when we would next say something, and then doing exactly that. Two rules I would keep anywhere. **Never state a cause you haven't confirmed.** The pressure to explain is immense, and a wrong explanation you have to retract costs more credibility than the original problem. "We don't yet know why, here's what we have ruled out" is a stronger position than a confident guess, even though it feels weaker to deliver. **Commit to the next update time, not the resolution time.** You cannot know when it will be fixed. You can absolutely control whether you speak again in an hour. Meeting that small commitment repeatedly is what rebuilds confidence, and it's entirely within your power even when nothing else is. ## The part that is genuinely hard The incentives run against halting and I do not think that fully resolves. A halt is a decision with your name on it and a number attached. Continuing and getting away with it produces no record at all. Someone who halts three times unnecessarily looks worse than someone who continued three times and got lucky, right up until the fourth time. The only counterweight I have found is reviewing the decision separately from the outcome. After every incident, ask whether the halt call was correct given what was known at the time, not given what turned out to be true. A team that only reviews outcomes will drift toward continuing, because most incidents do resolve without catastrophe and the drift feels like experience. It isn't experience. It's a sample of survivors. --- **Nick Sawinyh** is Head of Product and GTM at [Veodyn](https://veodyn.com/). He previously ran product and crisis communications for a top-ten DeFi lending protocol through multiple exploit events, and has spent over a decade taking technically complex products to market.