Engineering teams have been living with the same observability problems for long enough that most of them have stopped calling them problems. Slow incident response, deploys that go out without a clear picture of their blast radius, tooling stacks that cost more to maintain than they return in visibility -- these are accepted as the baseline cost of operating complex systems. We wanted to know how far that baseline was from what was actually achievable, so we pulled data from STRAND customers across six months and compared it against published industry benchmarks for engineering organizations of the same size and complexity. The gap was larger than we expected.
Incident Response
The industry median for mean time to recovery in engineering organizations running between 50 and 500 services sits at roughly 4.5 hours, according to data from the 2024 DORA State of DevOps report. That number reflects the full window from initial alert to confirmed resolution. The more telling number, and the one most teams feel acutely, is mean time to diagnosis -- the time between an alert firing and an engineer having an accurate picture of what is actually wrong. Industry median for that figure is just under 45 minutes.
Across STRAND customers in our dataset, mean time to diagnosis averaged 7 minutes. The difference is not attributable to faster engineers or better on-call processes. It is attributable to having a live, queryable dependency map available at the moment an incident starts. When an engineer does not have to reconstruct system topology from logs and documentation before they can begin diagnosing a problem, the diagnostic phase compresses dramatically. The remediation work that follows does not change. The time spent finding the starting point does.
Mean time to full recovery followed a similar pattern. STRAND customers in the dataset averaged 1.8 hours from alert to resolution, compared to the 4.5-hour industry median. The teams that saw the largest improvements were consistently those operating the most complex service graphs, where the time cost of manual topology reconstruction during an incident had previously been highest.
Deploy Confidence
A 2024 survey of engineering leaders across mid-size software organizations found that 71 percent of respondents described at least some portion of their production deploys as going out without a complete picture of downstream impact. The reasons varied -- outdated documentation, time pressure, incomplete dependency mapping -- but the outcome was consistent: changes shipping with an incomplete understanding of their blast radius, and post-deploy monitoring windows used to discover what pre-deploy analysis had not caught.
The cost of that gap shows up in post-deploy incident rates. Industry data puts the average rate of deploy-related incidents at roughly one for every twelve production deployments in organizations without structured pre-deploy impact analysis. For teams running high deploy cadences, that frequency accumulates quickly into a significant operational load -- incidents to investigate, rollbacks to coordinate, downstream consumers to notify.
Among STRAND customers running change impact analysis as part of their standard pre-deploy workflow, the deploy-related incident rate dropped to one in 47 deployments. The analysis step itself takes minutes. What it catches -- high-risk downstream paths, consumers that would be affected in non-obvious ways, dependencies that are not reflected in current documentation -- is the category of problem that would otherwise surface after the deploy, when it is more expensive to address.
Operational Overhead
The average engineering organization running between 100 and 500 services maintains 4.2 separate observability and monitoring tools, according to survey data from the 2024 Cloud Native Computing Foundation annual report. Each tool covers a different slice of the system. None of them share a dependency model. The result is a fragmented observability picture that requires engineers to hold context across multiple systems simultaneously during the moments when clear, unified visibility matters most.
Maintaining that toolchain carries a cost that rarely appears in a single line item. There are vendor contracts, integration maintenance, dashboard upkeep, and the ongoing overhead of reconciling conflicting data across systems that do not agree on the state of the same service. Engineering time spent on that work is engineering time not spent on the systems being observed. Teams absorb this cost gradually enough that it becomes invisible.
STRAND customers in our dataset replaced an average of 3.1 monitoring tools per team after deployment. The consolidation removed the integration maintenance overhead, eliminated the context-switching from incident response, and gave every engineer on the team a single workspace that stayed current automatically as the system changed. The teams that had previously been spending the most time maintaining their observability stack saw the largest recoveries in available engineering capacity after consolidating.
Onboarding time followed the same pattern. The industry average for getting a new infrastructure or platform engineer to independent contribution is 3.8 weeks, a figure that reflects how much of that time is spent building a mental model of a system that has no accurate external representation. Across STRAND customers, that average was 6 days. The dependency map gave new engineers something to study and orient against from day one, rather than depending on documentation that was already outdated or knowledge transfers from senior engineers who had other things to do.
What the Gap Costs
The difference between the industry baseline and what STRAND customers see is not primarily a technology gap. It is a visibility gap. Teams operating without an accurate, live model of their system dependencies spend time compensating for that absence in every part of their work -- in incident response, in deploy processes, in onboarding, in the overhead of maintaining tooling that still does not give them the full picture. That compensation cost is real, but it is diffuse enough that it rarely gets measured directly.
The teams in our dataset were not exceptional. They were not running unusually mature engineering organizations or investing disproportionately in tooling and process. They were engineering teams of ordinary size and complexity who had a complete, accurate, continuously updated map of their systems available when they needed it. The benchmark gap follows directly from that.