Bamboo-JIRA integration build result propagation timing under load

Timing of JIRA Issue Transitions

In Bamboo Server and Data Center (including 9.x), JIRA issue transitions are triggered as post-build actions. The timing is determined by the completion of the build result calculation: once the build process exits and the result is determined, Bamboo dispatches a REST API call to JIRA to update the associated issue status. Under load, the two contributors to this gap are Bamboo's internal event queue and JIRA's REST request processing latency.

Build Success vs. Transition Completion

Bamboo reports build success independently of the JIRA transition result. The build is marked as Successful or Failed based on the build process exit code, and that status is committed to the Bamboo database before the external JIRA request is dispatched. Because the REST call is asynchronous relative to the build's internal state transition, Bamboo will report the build as finished before the JIRA issue is necessarily transitioned.

Conditions under which success is reported before the transition completes:

• Standard operation: by design, the build status is committed to the database before the integration request is sent.
• JIRA-side latency: under high load, REST API processing time or thread pool exhaustion in JIRA delays the transition.
• Network congestion: latency between the Bamboo and JIRA servers inflates the gap without affecting build execution metrics.
• Rate limiting: if JIRA throttles incoming requests, transitions may be queued or delayed.

Distinguishing Propagation Delay from Queue Wait Time

In Server/Data Center 9.x, propagation delay is chronologically and logically distinct from build queue wait time. They occur at opposite ends of the build lifecycle, so they can be measured separately:

Verification Steps

1. Timestamp comparison: compare the Build Finished timestamp in the Bamboo build result with the Updated timestamp in the JIRA issue history. The difference is your propagation delay.
2. Log analysis: review JIRA access logs to identify the exact arrival time of the transition request relative to the Bamboo build end time.
3. Error tracking: scan Bamboo server logs for remote-call or integration timeouts during peak load periods.

Assumptions and uncertainty: this describes Bamboo Server/Data Center 9.x behavior; Bamboo Cloud uses a different integration architecture and these findings may not apply. Exact event-queue internals are version-dependent, so confirm against your release's logs. One diagnostic detail would change the recommendation: whether you run a single-node Server instance or a multi-node Data Center cluster, since cluster event propagation can add internal latency.