Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Use a Buildkite organization’s webhook notification service to sync pipeline builds to Flashduty On-call. Each build becomes one Flashduty change; every state of the build, from scheduled and running through failing to passed, failed, or canceled, updates that same change. We recommend sending only deployment pipelines: select those pipelines in the webhook, or use branch filtering to send builds of release branches only.

​
In Flashduty On-call

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

​
Configure Buildkite

1

Add a webhook notification service

In your Buildkite organization, go to Settings → Notification Services and click Add next to Webhook. You need organization admin permission.
2

Enter the Push URL

  1. Description: a name you can recognize, such as Flashduty
  2. Webhook URL: paste the complete Flashduty integration Push URL
  3. Token: keep the default; Flashduty authenticates with the integration_key in the Push URL
3

Select events and pipelines

  1. Under Events, select build.scheduled, build.running, build.failing, build.finished, and build.skipped
  2. Under Pipelines, choose the pipelines to send (all, specific pipelines, or the pipelines of specific teams or clusters)
  3. To send only some branches, enter branch patterns under Branch filtering; leave it empty for all branches
  4. Click Add Webhook Notification to save

​
What one change is

One build is one change. Its change identifier (change_key) is the build’s build.id, a UUID unique across Buildkite. Every build.* event of the same build updates the same change; two builds of the same pipeline and branch are two changes, and a rebuild creates a new build and a new change.

​
Status mapping

Flashduty takes the status from build.state in the delivery: Done, Failed, and Canceled are end states; Flashduty records the change’s end time when one arrives. A build waiting on a block step is delivered as build.finished with state passed and blocked set to true; Flashduty records it as Planned and updates it to the final status when the build continues and finishes. These deliveries return success but create no change: ping and other non-build events such as job.*, agent.*, and cluster_token.*.

​
Change content

Use labels for routing and for filtering the change list:

​
FAQ

  • Make sure the webhook has the build.* events selected; job.* or agent.* events alone create no changes
  • Make sure the build’s pipeline and branch are within the webhook’s Pipelines and Branch filtering settings
  • At the bottom of the webhook settings page, click Load recent requests to see the last 20 deliveries and Flashduty’s responses
No. An event with the same state and time is recorded only once.
  • unsupported build.state: Flashduty received a build state it does not support yet; contact us
  • build.id is missing: the delivery is incomplete; make sure it comes from Buildkite’s webhook notification service