I have about six years of overall experience, including roughly two years in DevOps and infrastructure, and I'm based in India. Recently, I've been working close to 12 hours almost every day, even though I'm not on call. The workload keeps expanding because management regularly says I have enough bandwidth for another task, and it feels like nothing is ever considered finished.
Is this simply part of working in DevOps or infrastructure? Does it improve as you gain experience and become better at automation and prioritization, or does the pressure usually continue as you progress? Is this mainly a company or regional work-culture issue, and would changing employers likely make a meaningful difference? I'd especially appreciate perspectives from people who have been in the field for several more years.
5 Answers
You’ll probably need to set boundaries yourself, because “you have bandwidth” can turn into an endless stream of extra work. Keep a visible list of everything you’re responsible for and ask your manager which existing task should be delayed when something new is assigned. That makes the capacity problem explicit instead of silently absorbing more work. It may not be safe to refuse bluntly in every workplace, but prioritization is still a management responsibility—not something you should solve by working indefinitely.
It can get easier as your technical judgment improves, but that usually means you become better at automating, saying no, and identifying what can wait—not that the role magically becomes less demanding. If the current workload is the daily baseline rather than a temporary project, start documenting your hours and responsibilities, have a direct conversation about priorities, and consider moving to a team with healthier expectations. Burnout is not a required part of a DevOps career.
The experience varies widely. Startups and understaffed teams can demand very long hours, while mature organizations may have scheduled work, rotating on-call coverage, and clearer ownership. Some people also work across time zones, which can make the day feel endless. But geography alone doesn’t determine the outcome, and being in a particular region shouldn’t be treated as the explanation for poor working conditions. When comparing jobs, ask directly how often people work late, how overtime is handled, who covers incidents, and what happens when the backlog exceeds capacity.
That schedule is much more about the company and team than the DevOps title. I’ve seen infrastructure roles that were constant firefighting and others where the normal workload was closer to a regular 40-hour week. Occasional incidents happen, but working 12 hours nearly every day—especially when you aren’t on call—is a major warning sign. A different employer could absolutely improve things, so ask about workload, on-call rotations, staffing, and expectations during interviews.
Good DevOps practices should reduce repetitive work through automation, reliable deployment pipelines, monitoring, documentation, and shared ownership. They aren’t supposed to turn one person into a permanent emergency responder. If everything is still manual and every request is urgent, the organization may be using the label without adopting the practices that make the work sustainable.
That approach only works if management is willing to prioritize. Some companies will still threaten people who push back, so checking the culture and quietly looking for alternatives may be necessary.