The metric nobody measures: how long until the bleeding stops?

Every incident dashboard tracks time-to-detect and time-to-resolve. Nobody names the interval that actually decides how much an outage hurts. That’s the gap between knowing what’s wrong and making it stop. In this article, we propose a name for it and dive into why the biggest companies on earth are leaving it on the table.

On November 18, 2025, a routine database permissions change took a large slice of the internet offline. X, ChatGPT, Spotify, Canva, and thousands of other sites started returning HTTP 5xx errors. The cause wasn’t an attack. A query started returning duplicate rows, which doubled the size of a configuration file that Cloudflare’s bot-management system pushes to its edge every few minutes. The oversized file blew past a hard memory limit and the core proxy crashed worldwide.

The impact began around 11:20 UTC. Engineers didn’t confirm the actual trigger until about 13:37 UTC. They stopped generating new bad files and pushed a known-good version at 14:30 UTC, at which point most traffic recovered. Full resolution came at 17:06 UTC. That’s five hours and thirty-eight minutes end to end.

Now split that number in two. Roughly the first two hours were spent figuring out what was going on because the failure had a maddening saw-tooth pattern that made it look like an attack or a flapping dependency. The actual mitigation, once they understood it, was reverting one config file. The fix was fast. The knowing was slow, and then the recovery from a globally-propagated bad state was slow after that.

This is the shape of almost every large modern incident, and our shared vocabulary for measuring it is missing a word.

The reason is that we treat it as one event when it’s really five.

Anatomy of an incident, interval by interval

When we say MTTR (Mean Time To Recovery/Resolution) we usually wave at a single duration: something broke, then it was better. But a real incident is a sequence of distinct intervals, with different levers for improvement. Flattening them into one number hides where your time actually goes.

Reading left to right:

1. A fault is introduced, but there’s usually a lag before it causes user-visible impact.
2. Then comes MTTD (detect): how long the impact runs before anyone knows.
3. Then MTTA (acknowledge): a human engages and figures out what is actually wrong.
4. Then mitigation.
5. And finally resolution.

The line that matters in that diagram is the amber band, because it’s the only part your users actually experience. And notice that it ends at mitigated, not at resolved.

Our proposal: Mean Time to Neutralize (MTTN)

Everyone measures detection obsessively. Resolution gets measured too, because it closes the ticket. But the interval that decides how bad an incident actually gets is the one between knowing what’s wrong and making the impact stop. And it rarely has its own name or its own number on the dashboard.

MTTN (Mean Time to Neutralize): The time from diagnosis to impact reaching zero, regardless of whether the underlying bug is fixed. It measures how fast you can stop the bleeding, not how fast you can heal the wound.

MTTN is deliberately not MTTR. Resolution means the real fix is written, reviewed, deployed, and fully propagated. Neutralization just means users stopped hurting. In a world where the only tool you have is shipping code, these two collapse into the same moment. Impact ends exactly when the fix goes live, and not one second sooner. That’s the assumption baked into most incident math and we believe it’s worth breaking.

Because there is another tool. If the offending behavior sits behind a runtime control mechanism such as a feature flag or a kill switch you can change without a deploy, then neutralization is a switch flip, not a deploy pipeline. You don’t wait for a build or for a canary deployment. You change the state of the running system directly, and the bad code path stops executing in seconds.

In the bottom timeline, the amber band collapses down to MTTD + diagnosis + a few seconds of propagation.

The fix hasn’t gotten any faster, and writing correct code under a real root cause still takes as long as it takes. What changed is that the users stopped paying for it.

The Mitigation-Resolution Gap (MRG)

Look again at the bottom timeline. There’s now a stretch of time between neutralized and resolved. The impact is already over, but the real fix hasn’t shipped yet. That span tells you something the other numbers can’t.

MRG (Mitigation-Resolution Gap): The time between impact-neutralized and fix-fully-deployed. In a deploy-only shop this gap is essentially zero because impact ends only when the fix ships. With runtime control it can be hours or days. And a wide gap is a sign of health, not dysfunction.

This one runs against instinct. Almost every other duration in incident response is something you want to minimize. MRG is the opposite. A wide MRG means your users stopped hurting long before your engineers were finished and that you bought your engineering team hours of unpressured time to write a correct fix instead of a panicked one.

An MRG near zero means the only way you know how to stop an incident is to deploy your way out of it, live, under maximum pressure, with the graph still bleeding. That’s the perfect recipe to make things worse, like the rushed hotfix that introduces a second bug. Or the rollback that corrupts state. Or the “quick” production change that ends up as the subject of the next postmortem.

In other words: the goal during an incident is not to fix the bug quickly, but rather to stop hurting users quickly, and then fix the bug correctly without pressure.

This allows you to reframe MRG as the breathing room to work on the long-term fix. That reframe, more than any tooling change, is what shifts how a team reasons about resilience. Unfortunately, it’s completely invisible if your tooling can’t separate mitigation from resolution.

Runtime Control Coverage: how much of your system even has a switch?

In the real world, MTTN and MRG only exist for incidents that have a runtime control to flip. Think of a crash in un-flagged core infrastructure, a data-corruption bug, a problem in code whose flag was removed months ago. None of those have a kill switch, and for those you’re back to deploying under pressure.

So the honest prerequisite question is: what fraction of your production changes are even eligible for fast neutralization?

RCC (Runtime Control Coverage): The share of production changes shipped behind a runtime-controllable switch, or the fraction of your incident surface that has a kill switch available. It’s the maturity metric underneath the other two: it tells you how much of your system MTTN and MRG can even apply to.

RCC is what turns runtime control from a lucky break into a discipline. If only a handful of features are flagged, you’ll occasionally get a fast save and mostly won’t. If you treat “every meaningful change ships behind a flag” as the default, your neutralizable surface approaches the whole system and MTTN becomes something you can rely on during an incident.

Where this doesn’t save you

Runtime control is not a universal undo button, so let’s clarify where it does and doesn’t apply.

First, neutralization only works on flag-gated behavior. The Cloudflare incident is instructive because the failure was in a config-distribution path, not a single tidy feature, which is why a global kill switch for that subsystem is one of the remediations they pointed toward in the postmortem. The lesson is that the systems most worth wrapping in a switch are the ones whose blast radius is global.

Second, “neutralized” is not always literally instant. A flag flip still has to propagate: SDK cache TTLs, streaming versus polling update models, and edge caching all sit between the switch and when every server actually stopped serving the feature. That propagation window is itself part of MTTN, and minimizing it is a real engineering concern. It’s the difference between seconds and minutes of extra impact.

Third, none of this reduces how often you break things. That’s change failure rate, a separate DORA metric with its own levers (testing, progressive rollout, review). MTTN doesn’t make you fail less, but it makes each failure cost less. Both matter.

How this fits with the metrics you already track

MTTD, MTTA, and MTTR come from the SRE and incident-management tradition. The five DORA metrics are deployment frequency, lead time for changes, change failure rate, failed-deployment recovery time, and deployment rework rate (new since 2024).

The new metrics we’re proposing (MTTN, MRG, and RCC) are a new layer that sits on top, describing the ability to change a running system’s behavior without a new deployment.

And runtime control improves the DORA numbers too. Decoupling deploy from release shortens lead time, because you can ship code turned off and then turn it on later. Instant rollback improves failed-deployment recovery time. But the reason to name MTTN, MRG, and RCC separately is that the existing metrics have no vocabulary for “stop the impact now, fix the cause later”. And what you can’t name, you can’t measure or improve.

The part the largest companies still haven’t internalized

Feature flags aren’t new. Kill switches aren’t new. What’s still surprisingly rare is treating runtime control as core incident infrastructure rather than a developer convenience, even among organizations running globally distributed systems where an outage costs millions per hour.

When Wayfair moved to Unleash, they migrated more than 15,000 feature flags across 1,000+ developers, a company that had previously taken holiday-season downtime measured in millions of dollars per hour. The point of that scale of coverage is that a huge fraction of their production surface is neutralizable: when something goes wrong, the first move can be a switch rather than a scramble.

Unleash is built for exactly this: flag evaluation happens locally in your own infrastructure, updates propagate in near-real-time, and it runs at a scale of billions of evaluations a day.

That’s what puts the answer to “how long until the bleeding stops?” in seconds instead of hours, and lets the fix take exactly as long as it needs to.