Which idle-timeout setting minimizes cost for Bamboo elastic agents in low-traffic workloads?

To minimize monthly compute expenses in a low-traffic environment, set the idle-timeout to the lowest possible value (typically 0 or the minimum supported integer). In low-traffic scenarios, the cost of maintaining an idle instance far outweighs the one-time 30–90 second provisioning latency incurred during a cold start.

Cost Analysis: Timeout vs. Provisioning

The primary driver of cost for elastic agents is the duration the instance remains active. Because low-traffic workloads have sporadic build triggers, any timeout greater than zero creates a "cost tail"—a window where you pay for compute resources that are not executing code.

Minimum Idle Agent Count: Zero vs. One

• Minimum Count = 0: This is the most cost-effective setting. It ensures that when no builds are queued, no instances are running. During a spike, Bamboo will provision agents on demand. While the first build in a burst will experience the full provisioning delay, subsequent builds in that same burst may reuse agents if they finish within the idle-timeout window.
• Minimum Count = 1: This eliminates the cold start for the first build but introduces a constant baseline cost. For low-traffic environments, this usually results in significant waste, as the instance remains active 24/7 regardless of build frequency.

Implementation Steps

1. Navigate to the Bamboo Administration console.
2. Locate the Elastic Agent configuration settings.
3. Set the Idle Timeout to the minimum allowed value to ensure immediate termination after job completion.
4. Set the Minimum Idle Agents to 0.

Verification and Constraints

To verify the effectiveness of these settings, monitor your cloud provider's billing logs (e.g., AWS Cost Explorer) to ensure instance uptime closely aligns with actual build execution times.

Note: Be aware of your cloud provider's minimum billing increments. If your provider bills by the hour rather than the second, extremely aggressive timeouts may not yield proportional savings. Additionally, if your "low traffic" actually consists of frequent, small bursts (e.g., every 2 minutes), a 0-second timeout may cause "thrashing," where the overhead of constant provisioning becomes a bottleneck.

To refine this recommendation: Please provide the average time interval between your sporadic build triggers.