You feel like DevOps is breaking down. If you're a CTO or product manager running a lean engineering team, you've felt it: DevOps shifted from enabler to bottleneck.
What started as a way to move faster now creates toil, context-switching, and more late-night work.
We surveyed 135 engineers, platform leads, and CTOs to understand where teams get stuck. The results show clear patterns about what's breaking down and where teams need relief. All of our insights come from our report: AI + DevOps Report.
Here’s what the data told us.
Key Takeaways
- DevOps is hitting a breaking point. Teams report mounting friction, burnout, and delays as complexity outpaces tooling and capacity.
- The human cost is climbing: 47% of engineers say DevOps overload contributes to burnout, especially during on-call and repetitive maintenance work.
- AI is entering the DevOps stack: 67% of organizations increased AI investments in 2025, mainly for automation, anomaly detection, and compliance support.
1. Nearly 30% of Engineers Spend a Third of Their Week on Infrastructure Tasks
This stat means different things depending on your role and team size.
For a dedicated platform team at a 500-person company, spending 30% of time on infrastructure is the job. For product engineers at a 50-person startup who should be shipping features, losing 2 days a week to Terraform reviews and Kubernetes troubleshooting is a disaster.
The fundamental insight: this work doesn't scale in the linear way that you might expect.
A team of 10 engineers might spend 5% of their time on infrastructure. A team of 100 might spend up to 40% of its time fixing infrastructure issues. The complexity curve gets steep fast.
Infrastructure as Code (IaC) helped, but also created new problems. Teams now maintain thousands of lines of Terraform, review infrastructure PRs, and debug state file conflicts. We automated execution but added a new layer of code to manage.
What this means for you:
- Under 20 engineers: Your DIY setup works fine. Don't over-engineer it.
- 20-100 engineers: This is where pain starts. You need clearer standards with self-service tooling or dedicated platform support.
- 100+ engineers: Without DevOps automation that lets developers self-service, this percentage will keep climbing.
2. 62% of Teams Say Security and Compliance Is Their Top Challenge
Security and compliance dominate the 2026 DevOps conversation. The regulatory landscape keeps expanding. SOC 2, HIPAA, PCI-DSS, GDPR, and now AI-specific regulations all demand audit trails, access controls, and documented policies.
Most organizations still handle audits manually. One in three teams reported that a single audit takes over a week to complete. That's a week where engineers produce spreadsheets instead of features, launches get delayed, and human error creates the exact vulnerabilities that regular audits are meant to prevent.
Here's what makes doing audits even harder: compliance requirements stay vague until you're in the audit.
"Demonstrate least privilege access" sounds simple until you're documenting permissions across 47 microservices, three cloud providers, and two Kubernetes clusters.
The real challenge: compliance scales with system complexity, not headcount. Adding more engineers without better tooling just means more things to audit.
What this means for you:
- Early stage with no compliance requirements yet: Enjoy it while it lasts. Build with compliance in mind from day one.
- First audit coming up: Budget 2-3x longer than you think. Document everything now.
- Regular audits: If you're doing this manually, you're burning money and risking errors. Automation pays for itself quickly here.
3. Only 29% of Teams Can Deploy On Demand
Here's the gap that matters: 58% of teams say faster deployment and shorter lead time to change are their top priorities heading into 2026. Fewer than 3 in 10 organizations can actually deploy when needed.
This isn't just about CI/CD pipelines. Teams that can't deploy on demand usually face one of these blockers:
- Fear-driven process: Every deploy needs three approvals and a maintenance window because the last one broke production
- Environmental complexity: "It works in staging" is followed by two days of debugging why prod differs
- Tribal knowledge: Only one DevOps engineer, the team's “hero” knows how the deploy actually works, and she's in a meeting
- Tool sprawl: The deploy process touches six different systems that don't talk to each other
The data shows something else, too, that many CTOs can easily overlook:
- Deployment speed correlates with team confidence. Teams that deploy more are, for the most part, more confident and make fewer mistakes.
- Teams that deploy frequently have better rollback procedures, better monitoring, and less fear.
- Teams that deploy rarely treat each deploy as if they were defusing a bomb.
What this means for you:
- If you can't deploy daily, start by understanding why and how to overcome this challenge. Is this a technical or cultural issue?
- If deploys feel scary: You need better observability and rollback mechanisms before you need speed.
- If you're deploying multiple times per day: You've solved the hard part. Now focus on what you're deploying.
4. 47% of Engineers Report Burnout From DevOps Overload
Behind every failed deployment and botched audit is a person. And that person might be exhausted.
Nearly half of engineers say DevOps overload contributes to burnout or frustration. The always-on nature of infrastructure work, combined with increasing complexity, creates unsustainable conditions.
Tribal knowledge makes this worse. Often, only a handful of engineers understand how systems really fit together. When those people leave, burn out, or go on vacation, the whole operation becomes fragile. This is more just a meme; it's a real operational risk.
Here's what the numbers don't capture: the emotional weight of being on-call for systems you didn't build and don't fully understand. Or the stress of knowing your Terraform mistake could take down production.
Or the frustration of spending your Saturday debugging a networking issue instead of building the feature you're excited about, or taking the weekend entirely off and coming back to work recharged.
What this means for you:
- If only 2-3 people understand your infrastructure, you have a documentation problem and a knowledge-sharing problem
- If your best engineers are leaving: Ask them about DevOps toil in exit interviews
- If on-call is brutal: Your observability and incident response need work before anything else
Burned-out engineers make mistakes. And in infrastructure, mistakes are expensive to find and fix.
5. 67% of Organizations Increased AI Investment in DevOps This Year
Here's the number that signals change: two out of three teams increased their investment in AI for DevOps in 2025. Nearly 80% say they're open to agent-based automation, with a big caveat: they want guardrails like approval workflows and rollback options.
Let's be clear about what this actually means. "Open to" isn't the same as "actively using." The market is in exploration mode, not adoption mode. Teams are curious, but cautious.
Where AI actually helps today:
- Pattern recognition in logs and metrics (anomaly detection)
- Generating boilerplate IaC from specifications
- Suggesting fixes for common errors
- Automating routine tasks with clear success criteria
Where AI still struggles:
- Understanding your specific business context
- Making judgment calls about tradeoffs
- Handling novel problems it hasn't seen before
- Debugging complex, multi-system failures
The shift from copilots (AI that suggests) to agents (AI that acts) is early but not fully there yet. Most successful implementations keep humans in the loop for approval, especially for production changes.
What this means for you:
- Don't ignore AI, but don't engineer everything based on what AIs can or can’t do
- Start with low-risk, high-repetition tasks where mistakes are cheap
- Build approval workflows and audit trails from day one
- Measure actual time savings, not theoretical ones
Teams that see real value from AI treat it as a tool that enables developer self-service, not as a replacement for engineering judgment.
What the Data Actually Tells Us
These five numbers point to a common thread: DevOps complexity is outpacing team capacity. The tools that helped us scale from 10 to 100 services don't work as well from 100 to 1,000.
But the right answer differs for every organization:
- If you're a 10-person (or fewer) startup, your DIY setup is fine. Focus on product-market fit. Don't over-engineer your infrastructure, especially not when every last engineer is needed to build new products and features.
- If you've got 50-200 engineers, it’s usually during this phase of growth that the pain curve gets worse. You need to either build robust self-service tooling internally or adopt DevOps automation that abstracts away the complexity. Muddling through with your current approach will slow you down.
- If you've got 200+ engineers, you need automation that lets developers provision, deploy, and manage infrastructure without becoming infrastructure experts. Whether you build this capability or buy it, the alternative is hiring a large team just to handle tickets and IaC stress, and no one wants that.
The broader question these numbers raise: Are we solving for the right problem? Sometimes the bottleneck isn't DevOps tooling or a lack of DevOps automation. Sometimes the problems stem from unclear ownership, poor architectural decisions, or organizational dysfunction that no amount of automation will fix.
Why DuploCloud Did This Research
At DuploCloud, we built our platform because we kept hearing the same frustration from engineering teams: "Our developers just want to ship code, but they're buried in infrastructure tickets and security reviews."
We wanted to move beyond anecdotes and put real data behind what we were seeing. This survey gave us a benchmark. It confirmed some assumptions (compliance is brutal) and surprised us on others (the deployment gap is wider than we thought).
The pattern that emerged is clear: teams need a way for developers to self-service infrastructure without sacrificing security, compliance, or reliability. Whether that's through tools like DuploCloud or building sophisticated internal automation, the goal is the same: let developers focus on creating products that drive revenue.
We're sharing this data because the entire industry benefits when we're honest about what's working and what isn't. The more transparently we can talk about these bottlenecks, the better solutions we'll all build.
The Questions CTOs Should Be Asking
DevOps is becoming more challenging, but it’s too soon to declare any approach useless. What we need to think about are better ways to solve the problems you’re currently having:
- Where are we actually blocked? (Not where we think we should be blocked)
- Can our developers provision what they need without waiting on tickets?
- What keeps our best engineers from doing their best work?
- Are our DevOps problems technical, organizational, or both?
- What's our actual risk tolerance for automated changes?
The data suggests a shift is coming. AI and automation will play a bigger role in DevOps. But the path forward depends on your scale, your risks, and your resources.
The teams that win won't be the ones who adopted AI first or held onto DIY longest. They'll be the ones who honestly assessed their constraints and deliberately chose where to invest.
Want to see the whole dataset and methodology? See the full findings in our AI + DevOps Report. 135+ engineers, platform leads, and CTOs share what really slows deployments and how they’re rethinking what “fast” means.
Consult a DevOps expert today to see if DuploCloud could be the one-stop solution to your DevOps needs.
Frequently Asked Questions (FAQs)
What constitutes “deploy on demand”?
In the survey’s framing, “deploy on demand” means the ability to push changes to production in a time frame they’re comfortable with, without waiting for major manual gates, approvals, or windows. The low 29% suggests that processes, risk controls, or divergent environments still constrain many teams.
How is “burnout from DevOps overload” measured?
The survey likely asked whether respondents feel DevOps tasks contribute to frustration, stress, or burnout. The 47% is self-reported, subjective, and correlational (i.e., it doesn’t prove causality). But it shows a strong signal that many engineers perceive DevOps work as stressful.
Why do so many teams still struggle with security and compliance?
Despite increasing regulatory pressure (GDPR, SOC 2, HIPAA, etc.), many teams continue to use manual processes for audit, access control, and policy enforcement. The complexity of microservices, multiple clouds, dynamic infrastructure, and vague audit requirements exacerbates the burden. The report highlights that compliance often scales not with the number of engineers, but with system complexity.
What does “increased AI investment in DevOps” actually mean in practice?
It usually means dedicating more budget, tooling, or experimentation toward AI/ML and agentic workflows in operations, automation, or observability. But being “open to agents” or having pilots doesn’t always translate into full production use. The report emphasizes that many teams are cautious: they want guardrails, rollback paths, and human oversight.
