Here's something I see in almost every Azure DevOps environment I review. Self-hosted build agents running around the clock, regardless of whether anyone is actually deploying.
A VM sitting idle at 2am on a Saturday, waiting for a pipeline that won't trigger until Monday morning. That's like leaving the office lights on all weekend because someone might pop in. You wouldn't do that with your electricity bill. Why do it with your Azure bill?
The always-on agent problem
Traditional self-hosted agents are VMs. You provision them, install the agent software, register them in a pool, and they sit there waiting for work. Azure charges for every hour those VMs exist, whether they're running builds or gathering dust.
Most CI/CD pipelines follow predictable patterns. Builds trigger during business hours when developers push code. Deployments happen during release windows. PR validation runs when someone opens a pull request. The rest of the time (evenings, weekends, bank holidays) the agents idle. The billing doesn't.
A single D2s_v5 agent running 24/7 costs roughly £65/month. A D4s_v5 with more grunt for larger builds is closer to £130. Scale that to a team running four or eight agents and you're looking at £500-1,000/month in compute for machines that spend the majority of their time doing nothing.
Managed DevOps Pools change the model
Managed DevOps Pools let you define agent pools where infrastructure is provisioned on demand rather than running continuously. The key setting is the standby agent count, and the number that changes everything is zero.
With standby set to zero, no VMs exist in your pool until a pipeline needs one. A pipeline triggers, the pool provisions a fresh VM from your configured image, the agent registers, picks up the job, runs it. Once the job completes, the VM is deallocated.
No pipeline running? No VMs. No VMs? No cost.
The trade-off: cold start time
If no VM exists, how long does it take to get one? Typically two to five minutes, depending on VM size and image complexity.
For a lot of teams, that's perfectly fine. If your build takes fifteen minutes, adding three minutes of provisioning brings it to eighteen. A twelve percent increase in wall-clock time in exchange for eliminating your agent costs during every hour nobody is building.
The question to ask isn't "is three minutes acceptable?" It's "is three minutes acceptable given what we're saving?"
The cost comparison
Take a team with eight self-hosted agents running D2s_v5 VMs.
Traditional self-hosted (24/7):
| Item | Cost |
|---|---|
| 8 × D2s_v5 agents | ~£520/month |
| OS disks (8 × P10) | ~£120/month |
| Total | ~£640/month |
Roughly £7,700 a year in agent infrastructure.
Managed DevOps Pools (zero standby):
Say the team runs 15 builds/day averaging 30 minutes each. About 225 compute hours per month across all agents.
| Item | Cost |
|---|---|
| ~225 compute hours @ ~£0.09/hr (D2s_v5) | ~£20/month |
| Managed pool overhead | ~minimal |
| Total | ~£20-50/month |
Even generously accounting for provisioning overhead, you're looking at maybe £50-150/month depending on build frequency. Against £640.
Annual saving: potentially £6,000-7,000.
Not a rounding error. A line item worth eliminating.
The hybrid: standby scheduling
Zero standby is the most aggressive option, but Managed DevOps Pools also support scheduling. You can configure different standby counts for different time periods.
A sensible middle ground:
- Monday to Friday, 8am-6pm: 1 standby agent (instant builds during working hours)
- Monday to Friday, 6pm-8am: 0 standby agents (cold start only)
- Weekends and bank holidays: 0 standby agents
You're paying for one agent for ten hours a day, five days a week (roughly 50 hours per week instead of 168). That alone cuts always-on costs by 70%.
When zero standby works
Teams with infrequent deployments. Non-production pools. After-hours and weekend periods. Organisations with predictable deployment patterns.
Your production release pool might warrant a standby agent. Your dev/test pool almost certainly doesn't. You don't need the same configuration for every pool.
When you need standby
Production hotfix pipelines where every minute of cold-start is a minute of downtime you didn't need. High-frequency CI teams generating dozens of PRs per hour where cold starts frustrate people. Regulated environments with SLA-defined deployment windows.
The bigger picture
Zero-standby agent pools are part of a broader shift. The old model was to provision capacity for peak demand and accept the waste during off-peak. The new model is to provision capacity for current demand and accept the latency of scaling up.
If your agents are idle more than they're busy, and for most teams they are, you're paying for capacity you don't use. Zero standby fixes that.
Running self-hosted DevOps agents that sit idle most of the day? Get in touch, we help teams right-size their CI/CD infrastructure and eliminate wasted spend.