We tracked deploy-related incidents across 200 engineering teams over six months. The number that stood out was not how often things broke after a deploy. It was how long it took to find out where. On average, 47 minutes passed between a change shipping and an engineer having an accurate picture of what failed and why. That window is not a technical problem. It is a visibility problem.
The 47 minutes
When we broke the number down, roughly 20 to 30 minutes of it happened before any diagnosis had started. Engineers were opening dashboards, cross-referencing logs, and piecing together a picture of the system from tools that did not share a data model. The remediation work. The part most teams think of as the actual incident response was the smaller half of the total time.
The teams with the worst numbers were not running the most complex systems. They were the ones whose tooling gave them the most information in the most fragmented way. Four dashboards open simultaneously, each covering a different slice of the same incident, none of them aware of what the others were showing.
The deploy is not the problem
Every post-mortem we read pointed to the deploy. The timing matched, so the deploy became the story. But in most cases the deploy was not where the time was lost. The time was lost in the window between the alert and the moment someone could say with confidence: this service, this dependency, this is where we start.
Blind deploys are not deploys that ship broken code. They are deploys that go out without anyone knowing what they will touch. The change looks fine in staging. The blast radius gets assumed rather than verified. An upstream dependency nobody is actively watching starts behaving differently, and by the time the alert fires the connection between the change and the failure is not obvious.
What the gap actually costs
The teams in the dataset that had live dependency mapping and pre-deploy impact analysis in place were not having fewer incidents. They had roughly the same rate of deploy-related failures as everyone else. What differed was the window. Time to diagnosis in those teams averaged under eight minutes. The investigation phase consuming 20 to 30 minutes elsewhere was compressing to under five.
That difference does not come from better engineers or more rigorous process. It comes from having the system already mapped at the moment the alert fires. When the dependency graph is live and accurate, the question of what is connected to the failing service has an answer that does not require anyone to remember it.
The 47-minute average is not a fixed number. It is what happens when the tooling makes visibility harder than it needs to be.