Controlling Bamboo Plan Execution: Enabled, Disabled, and Scheduled Policies

A Bamboo plan that fires on every repository push can quietly burn through agent capacity—or worse, run a deployment you didn't intend. Bamboo's per-plan execution settings let you decide whether a plan starts automatically, waits for a schedule, or stays off entirely until someone runs it manually. This guide covers how to set the policy, what each option actually does, and how to confirm the change took effect without stranding queued builds.

What the execution policy controls

Every Bamboo plan has an execution state that governs whether new builds can start. The three practical states are:

• Enabled — the plan runs whenever its triggers fire (repository polling, scheduled triggers, remote triggers, or manual runs).
• Disabled — the plan will not start automatically, even if a trigger condition occurs. Manual execution is also blocked while disabled, which makes this the right choice for decommissioning or freezing a plan.
• Scheduled — automatic trigger-driven starts are suppressed, but the plan still runs on its configured schedule or when started manually. This suits expensive nightly builds that shouldn't fire on every commit.

The policy only affects future runs. Builds already queued or in progress continue under the conditions that started them—disabling a plan does not drain its queue.

Prerequisites

• Admin permission on the specific plan (or global Bamboo admin). Without it, the UI rejects the change with a permission error, and REST calls return an authorization failure.
• Knowledge of the plan key (for example, PROJ-PLAN), visible in the plan's URL and details page.
• A clear picture of the plan's triggers. Before disabling anything, check whether other teams rely on its scheduled runs or downstream plans depend on its artifacts.

Setting the policy in the UI

1. Open the plan and go to Actions → Configure plan (or the plan details page, depending on your Bamboo version).
2. Find the Execution or Plan details section where the enabled/disabled state is shown.
3. Select the intended state and save. The change applies immediately to future runs.

Note that exact menu labels vary between Bamboo versions—older releases expose enable/disable as a toggle on the plan configuration screen rather than a dedicated "Execution" tab. Verify against your version's documentation if the labels differ.

Changing the policy via the REST API

For automation—say, disabling a batch of maintenance plans before an upgrade—use Bamboo's REST API from any machine with network access to the server. Run these with an account that holds plan admin rights:

# Disable a plan
curl -u USERNAME -X POST \
  https://bamboo.example.com/rest/api/latest/plan/PROJ-PLAN/enable \
  -H 'Content-Type: application/json' \
  -d '{"enabled": false}'

# Re-enable it later
curl -u USERNAME -X POST \
  https://bamboo.example.com/rest/api/latest/plan/PROJ-PLAN/enable \
  -H 'Content-Type: application/json' \
  -d '{"enabled": true}'

Replace USERNAME, the base URL, and PROJ-PLAN with your values. A successful call returns HTTP 200 with the plan resource; a 401/403 means the account lacks permission, and a 404 usually means a mistyped plan key. Endpoint paths can shift across Bamboo versions, so confirm against the REST API reference for your release before scripting against production.

Verifying the change

Don't assume the save worked—check it:

• Reload the plan's details page and confirm the displayed state matches your intent.
• Query the plan resource and inspect its enabled flag:

curl -u USERNAME \
  https://bamboo.example.com/rest/api/latest/plan/PROJ-PLAN \
  | grep -o '"enabled":[a-z]*'

• If you disabled the plan, push a trivial commit to the triggering repository and confirm no new build appears in the queue within the trigger's polling interval.

Risks and recovery

Missed builds. A disabled plan silently skips commits. If the plan feeds a release pipeline, document why it was disabled and set a reminder to re-enable it. Bamboo does not "catch up" on skipped commits when you re-enable—the next run builds whatever the repository looks like at that moment.

Queued builds still run. Disabling does not cancel builds already in the queue. If you need those stopped, cancel them explicitly from the plan's build activity view before or after changing the policy.

Permission lockouts. If misconfigured permissions leave nobody able to edit the plan, recovery requires a global Bamboo administrator to fix permissions, or in the worst case a database correction with Bamboo stopped. Treat permission changes on shared plans as carefully as the execution policy itself.

Rollback. Reverting is trivial: set the policy back to Enabled via the UI or the same REST call with {"enabled": true}, then verify with the GET request above and, if needed, trigger a manual run to confirm the pipeline is healthy.