Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Use a Bitbucket Cloud repository webhook to sync the build statuses on commits to Flashduty On-call. Bitbucket Pipelines, and third-party CI that publishes build statuses through the Bitbucket API, produce these events. Each build status becomes one Flashduty change; when the state moves from in progress to successful, failed, or stopped, the same change is updated. Bitbucket has no separate deployment event, so build statuses are the source of pipeline results. We recommend enabling the webhook only on repositories whose pipelines deploy.

In Flashduty On-call

  1. In the Flashduty console, go to Integration Center → Change Events
  2. Select Bitbucket and enter an integration name
  3. To assign changes to specific channels, add rules under the integration’s Routes that match labels such as repo or build_key
  4. Click Save and copy the generated Push URL

Configure Bitbucket

1

Add a webhook

In the repository, go to Repository settings → Webhooks and click Add webhook. You need repository admin permission.
2

Enter the Push URL

  1. Title: a name you can recognize, such as Flashduty
  2. URL: paste the complete Flashduty integration Push URL
  3. Status: keep Active
3

Select triggers

  1. Under Triggers, select Choose from a full list
  2. Expand Repository and select Build status created and Build status updated
  3. Click Save

How changes are merged

A Bitbucket build status has no id of its own; it is addressed by repository, commit, and status key (the API path /commit/<hash>/statuses/build/<key>). The created and updated events of one build status update the same change.
  • Build statuses with different keys on the same commit (for example a test check and a lint check) are two changes
  • The same key on two commits is two changes; Bitbucket Pipelines uses a distinct key for each run
  • If a third-party CI reuses one key on the same commit (for example when re-running), Bitbucket overwrites the status. In Flashduty the same change returns to in progress and is updated with the new final state when it ends

Status mapping

Flashduty derives the status from commit_status.state in the payload: Done, Failed, and Canceled are end states, and Flashduty records the change end time. STOPPED appears in the Bitbucket REST API’s state enum; the webhook documentation lists only the first three states. These deliveries return success but create no change: repo:push, pull request, comment, and other events that are not build statuses, and statuses whose type is not build.

Change content

The payload carries no branch, so there is no branch label. Use labels for routing and for filtering the change list:

FAQ

  • Confirm the webhook has Build status created and Build status updated selected; push and similar events create no change
  • Check the recent deliveries and Flashduty’s responses under the webhook’s View requests
  • Confirm the repository’s pipeline or CI actually publishes build statuses on commits
No. Flashduty records an event with the same state and update time only once. When a delivery fails, Bitbucket retries up to two more times; retries add no event.
  • … is missing or invalid …: the payload is incomplete or a field is malformed. Confirm it comes from a Bitbucket Cloud repository webhook
  • unsupported … or unknown …: Flashduty does not support this build status yet. Contact us