Elastic Bamboo Agent Scale‑Down: Missing Guaranteed Build Completion Timeout

Short answer

There is no configurable maximum wait time. During a scale-down, Bamboo waits for a running build to finish (or be cancelled) before deprovisioning the elastic agent — the wait is bounded only by the build's own duration. The internal heartbeat is hard-coded in the agent binary and cannot be tuned, and there is no built-in graceful-drain setting for busy agents. The only related knob, bamboo.agent.idle.timeout.minutes, applies exclusively to agents that are already idle.

What is confirmed vs. what is inferred

Confirmed behavior (Bamboo releases up to late 2026):

• When the elastic agent quota is reduced, Bamboo selects agents for deprovisioning but will not terminate one while it is executing a build. The agent is released only after the build's exit status is reported back to the server.
• The keep-alive heartbeat between agent and server is compiled into the agent code. No Bamboo property, JVM argument, or bamboo.cfg.xml entry exposes it.
• bamboo.agent.idle.timeout.minutes governs how long an idle agent lingers before shutdown. It has no effect on an agent mid-build.

Inferred / undocumented: the heartbeat interval itself is not documented; empirical observation of agent logs suggests roughly five minutes, but this is not guaranteed and could change between releases. Treat any specific number as unverified.

Practical implications

Because the wait is unbounded, a hung or pathologically long build will pin an agent indefinitely, keeping your elastic bill running. Since you cannot enforce a drain period server-side, the realistic mitigations are:

1. Cap build duration, not agent lifetime. Use build-level timeouts (per-job or per-task execution timeouts, or a wrapper script that aborts after N minutes) so that no build can hold an agent hostage.
2. Tune the idle timeout for fast turnover. Set bamboo.agent.idle.timeout.minutes low (e.g. 5–10) so agents are deprovisioned promptly after their build finishes, which is the only phase you can control.
3. Detect stuck agents operationally. Alert on agents whose uptime exceeds your longest legitimate build, and cancel the offending build manually — cancellation is what releases the agent.

How to verify on your instance

1. Start a deliberately long build (e.g. a sleep 1800 script task) on an elastic agent.
2. Reduce the elastic agent quota (or lower the maximum in the elastic configuration) and watch the agent list: the busy agent should remain until the build completes, while idle siblings disappear.
3. Inspect the agent log (atlassian-bamboo-agent.log) for heartbeat timestamps to confirm the interval on your version.
4. Lower bamboo.agent.idle.timeout.minutes, rerun, and confirm the agent is deprovisioned quickly once the build ends — and that the setting changed nothing while the build was running.

Caveats

This reflects Bamboo behavior through releases available as of September 2026. Atlassian could add scale-down or drain controls in later versions, so check the release notes for your exact version before relying on this. If you observe an agent being killed mid-build during scale-down, that would contradict the expected behavior — in that case, the Bamboo server log lines around the termination event would be the diagnostic detail needed to say more.