In the era of distributed architectures and complex service chains, the “black box” approach to networking is no longer sustainable. As applications span thousands of machines, unowned networks, and third-party SaaS providers, tools designed for a simpler, centralized era fail to keep pace. When a single user request triggers hundreds of dependencies, any inability to isolate issues quickly doesn’t just lead to technical debt. It leads to a cycle of burnout, finger-pointing, and significant financial loss.

To help organizations navigate this complexity, the latest edition of Splunk’s The Hidden Costs of Downtime report—developed in collaboration with Cisco ThousandEyes—shines a light on the critical role of the network in maintaining digital resilience. From the growing impact of AI-driven outages to the necessity of end-to-end visibility, this report provides a roadmap for IT leaders looking to modernize their infrastructure.

We sat down with Greg Leffler, Splunk Director of Developer Evangelism, to discuss the new report and his perspective on how to move past the blame game and build a more resilient, high-performing organization.

This second edition of The Hidden Costs of Downtime was more collaborative work. What are some of the biggest changes this brought to the new edition?

The biggest change in our 2026 Hidden Costs of Downtime report was a focus on networking-related downtime and its impacts, thanks to Cisco ThousandEyes experts like yourself. We found that most incidents (43%) stem from network- or IT environment–related issues like routing errors, network congestion, and challenges managing a vast amount of endpoint and IoT devices. One of the most significant findings we learned from ITOps and engineering leaders was that downtime caused by public cloud failures cost their organizations the most. So clearly, there was a need to focus on the network in this year’s report. When you think about it, customer experience is really dependent on external service chains companies neither manage nor fully understand. That’s why network end-to-end visibility is so important. It turns this “black box” into something that can be proactively monitored.

This year’s report also includes more insight into how AI is both a remedy for and a cause of downtime. While companies are turning to AI to find and fix issues faster, every technology executive surveyed admits their organization has experienced some form of AI-related downtime in the past year, whether from model drift, incorrect AI-driven automation, or adversarial attacks like prompt injections. Managing this paradox is going to be one of the greatest challenges for organizations moving forward.

[For additional insights on this topic, see The accelerating impact of AI on campus and branch networks.]

What role does visibility play in resolving complex network outages?

Visibility is essential. Without it, you simply can’t resolve issues effectively. If we’ve learned anything from the past few years, it’s that you need to be able to isolate a problem in seconds and start fixing it fast, because your customers aren’t going to wait. They’ll abandon their cart, go to a competitor, or vent their frustration on social media.

Perhaps because of this, organizations are starting to recognize the need to visualize the entire dependency chain. In fact, we found that among respondents with the lowest downtime costs, 98% say end-to-end visibility is very or extremely important for reducing downtime.

Why do traditional monitoring tools struggle with modern distributed architectures?

Because they were designed for a much simpler, centralized era. In the past, applications lived on a few servers that one person could easily manage and visualize. Today, applications are far more complex, running across thousands of machines in various locations and managed by many different teams. Traditional tools aren’t built to follow the path one user request takes in modern stacks, where one request can trigger hundreds of services, owned and unowned networks, and even third-party dependencies, like CDNs.

How do current incident response practices impact business innovation?

Incident response is still a game of hot potato. The first responder just wants to get the issue off their plate. Current tools don’t help with this; they fire off noisy alerts to the wrong people and often fail to provide diagnostic information needed to identify the root cause.

In addition, businesses need to ship code, which means that, occasionally, code will break in production. So, the traditional incident response approach of “roll everything back” just doesn’t cut it anymore. To effectively innovate, businesses should adopt A/B testing, feature flags, and other ways to exercise new business logic without needing complicated deployment. When one change has a negative business impact, they should be able to turn it off without doing more deployments and potentially breaking things even further.

Should IT leaders prioritize MTTI alongside MTTR?

No, I don’t think they should, because it implies that the siloed world where “only the network is my problem, and everything else is somebody else’s issue” is a good end state. It isn’t. Resilience is an organization-wide goal, where every issue is everybody’s problem. MTTI reinforces a laissez-faire attitude that is counterproductive to true digital resilience.

How does this approach improve the well-being of IT staff?

ITOps and engineering teams constantly report burnout because they are asked to do more with less in increasingly complex, high-pressure situations. So, being able to confidently say, “This problem is outside of my area of expertise, and here’s why,” can help ease burnout and allow teams to feel less anxious about work.

But there’s a delicate balance to strike here, as many IT staff that work in on-call roles enjoy being tasked with solving problems under pressure. You don’t take these jobs without embracing the tension of solving a “mission impossible” issue at hand.

What is the primary business value of reducing time spent in situation rooms?

The obvious one is the cost. According to The Hidden Costs of Downtime, Global 2000 companies lose $19 million from lost productivity and $13 million from overtime wages each year. And that’s only direct costs. Eighty-nine percent of technology executives admit that it requires many personnel to fix a downtime issue—a hidden cost that causes a chain reaction of consequences across an organization, like falling behind on product roadmaps. So, every second you have teams stuck in a war room is a second they’re not increasing overall value to your business.

How does this visibility benefit campus and branch network teams?

Visibility helps everyone by making it easier to rule out issues and quickly route problems to the right team, allowing them to resolve incidents with confidence. It’s frustrating to spend hours troubleshooting something only to find out your cat unplugged the router in the other room.

 

Save your seat for The $600 Billion Blind Spot: Why Downtime is Now a Boardroom Crisis webinar and learn how to quantify downtime’s hidden costs.

 

Additional resources:

• Download a copy of The Hidden Costs of Downtime 2026.
• Explore Cisco ThousandEyes Assurance.