Buildkite pipelines can now be triggered by a much broader set of GitHub webhook events — not just pushes and pull requests. This makes it easier to migrate GitHub Actions workflows to Buildkite incrementally, without losing triggers along the way.

New event triggers

You can now trigger pipeline builds from:

• Pull request reviews — run builds when a review is submitted or dismissed
• Check runs — react to completed check runs from other GitHub Apps, with built-in loop prevention for Buildkite's own checks
• Releases — trigger builds when a GitHub release is published, created, or released
• Issue comments — kick off builds from PR comments, with configurable command word filtering (supports exact and contains match modes)
• Pull request review comments — trigger builds from inline diff comments, with the same command word and match mode support (useful for AI assistant triggers like @claude)
• Deployment statuses — build when a deployment status changes
• Branch and tag creation — trigger on create events for new branches or tags

Expanded pull request actions

Pull request triggers now support additional actions beyond opened and synchronize:

Builds can now be triggered by edited, reopened, converted_to_draft, review_requested, and dequeued actions, in addition to the existing ready_for_review, labeled, and unlabeled actions.

Disable all webhooks

You can now disable all GitHub webhook-triggered builds for a pipeline with a single button. Select Disable GitHub Webhooks in your pipeline's GitHub settings to stop all webhook processing. Your existing trigger settings are preserved and restored when you re-enable.

Better filtering

GitHub webhook-triggered builds also now include BUILDKITE_GITHUB_EVENT and BUILDKITE_GITHUB_ACTION environment variables, available at runtime and in build.env() conditionals. These are also included as new conditional variables to make it easy to write fine-grained build filters:

• build.source_event — the GitHub event type (e.g. push, pull_request, release)
• build.source_action — the event action (e.g. labeled, opened, submitted)

We've also added build.pull_request.label, which allows for filtering on the specific label that was just added or removed, rather than the whole set of labels.

All the new events expose relevant context as environment variables via build.env() that you can use in pipeline and step conditionals. This allows for more fine-grained filtering before you start running builds and steps.

Learn more about configuring GitHub webhook triggers in our documentation.

You can now search for queues by name on the cluster queues page, making it much faster to find a specific queue when your cluster contains hundreds of them.

• Find queues quickly: Type any part of a queue name to filter the list instantly, with case-insensitive substring matching so you don't need to remember the full name or exact prefix.
• Fast, in-page updates: Results update in place as you search, without full-page reloads, and pagination continues to work across filtered results.
• Scales to large clusters: Built for customers consolidating many queues into a single cluster as part of a cluster migration, where scanning a paginated list is no longer practical.

If you manage a lot of clusters, you can now sort the Clusters page alphabetically and switch between the existing card layout and a new list view, making it much easier to find the right cluster without scanning a creation-ordered list.

• Sort by created date or name: Use the new sort controls to keep the default created-date ordering or switch to an alphabetical view when you need to find a cluster quickly.
• Switch between card and list views: Toggle between the familiar card layout and a new table view depending on how you prefer to scan cluster information.

• See more data in one place: The new list view shows cluster name, queues, pipelines, description, connected agents, running jobs, and waiting jobs in a sortable table that's easier to scan at scale.
• Keep your view during refreshes: Your selected sort and view settings are preserved during the page's automatic refresh.

You can now catch slow tests before they erode build speed with the Duration threshold monitor in Test Engine Workflows!

The Duration threshold monitor tracks how long individual tests take to run, and triggers when the aggregated duration over a sliding window crosses a configured threshold.

What's new

• Monitor test runtime against a configured threshold using a sliding window
• Full workflow action support including labeling, state management, Slack notifications, and Linear issue tracking
• Tag-based filtering to scope the monitor to specific branches, suites, or test groups

Learn more about the Duration threshold monitor in our documentation.

You can now retry all failed jobs in a build with a single API call, matching the behavior of the "Retry Failed Jobs" button in the UI.

REST: POST /organizations/{org}/pipelines/{pipeline}/builds/{number}/retry_failed_jobs GraphQL: buildRetryFailedJobs mutation

Both return the count of jobs queued for retry.

An optional filter parameter states lets you choose which job states to retry, so you can target exactly the failures that matter:

• failed: Jobs that ran and exited with a non-zero status
• soft_failed: Jobs that failed but were marked with soft_fail — the build continues regardless
• expired: Jobs that weren't accepted by an agent before the timeoug
• canceled: Jobs that were manually or programmatically canceled before completing

By default, all failed states are retried. Pass a filter to narrow it — for example, retry only failed jobs without re-queuing dozens of soft failures that would just add pressure to your queue.

Detail available in the GraphQL or REST docs.

User API access tokens now have an explicit GraphQL access mode. You can create tokens that can run GraphQL queries but not mutations.

When creating or editing a user API access token, the GraphQL permission offers three options:

• Disabled: No GraphQL API access
• Read-only: Can run queries, but mutations are rejected
• Full access: Can run both queries and mutations

Key details

• Existing tokens are unaffected: All previously created GraphQL-enabled tokens continue to work with full access.
• Mutation guard: Read-only tokens are blocked before any mutation code runs, so there is no risk of partial side effects.
• Audit visibility: The selected GraphQL access mode is displayed in the token summary and the organization API access audit view.

For more information, see the API access tokens documentation.

You can now save a default filtered view directly from the Tests tab. After configuring your filters, save them as your default view so the Tests tab loads with your preferred filters each time you visit.

This makes it easier to:

• Jump straight to the test results that matter most to your team
• Share a consistent, filtered view across your organization
• Reduce time spent reconfiguring filters between visits

Agents running buildkite-agent start now receive jobs in sub-second time, with no configuration changes necessary. Agent v3.122.0 replaces the polling-based dispatch with a persistent streaming connection, enabled by default.

What changed

Agent v3.122.0 changes the default agent API endpoint to agent-edge.buildkite.com, a new Go-based edge service that maintains a ConnectRPC stream to each connected agent. When a job is dispatched, it's pushed to agents over this stream rather than waiting for the next poll.

Why this matters

Previously, agents checked for work by polling every 10 seconds, plus random jitter to avoid synchronized requests across fleets. A job dispatched right after a poll could wait up to 20 seconds before that agent checks in again. Across a pipeline with many steps, that wait compounds.

With streaming dispatch, job acceptance latency drops to under 1 second. For an average build, that can save minutes of unnecessary wait time - resulting in faster and more efficient builds.

Availability

This is now the default for all agents running buildkite-agent start, including those on the Elastic CI Stack for AWS.

Buildkite Hosted Agents, Agent Stack for Kubernetes, and workflows using --acquire-job use different dispatch mechanisms and don't benefit from this change.

Upgrade to Agent v3.122.0 to get streaming dispatch by default. We'd love to hear how it goes! Reach out to support@buildkite.com with any feedback.

Annotations can now be scoped to individual jobs. Previously, all annotations lived at the build level, but with large builds this meant scrolling through a list of annotations and mentally mapping each one back to its job. Now, test failures, lint errors, etc. can show up next to the job that produced them. Existing annotations are unaffected — the default scope remains build.

🆕 What's new

• Job-scoped annotations via the agent CLI: Use buildkite-agent annotate --scope job to create an annotation that's tied to the current job.

  buildkite-agent annotate --scope job "3 tests failed — see details below"

• Annotation indicators on jobs: Jobs with annotations show an indicator on the canvas. When you open a job's drawer, its annotations are available in a dedicated Annotations tab.

  

• Annotations tab with build and job sub-tabs: The Annotations tab now has separate Build and Jobs sub-tabs, with links to jump to the originating job.

  

• Full API support: Job annotations are fully supported in both the REST API and GraphQL API, including create, read, and delete operations.

• Real-time updates: Annotations update in real-time as your build runs — no page refresh needed.

Job-scoped annotations require Buildkite Agent v3.112 or newer and are not available in the classic build page experience. For more information, see the annotations documentation.

Steps on the build canvas now display their run duration directly on each node, so you can quickly spot slow steps and see the progress of running jobs without clicking into them. Steps that haven't started yet show a -- placeholder, so you can see at a glance which parts of your build are still waiting to run.

Group steps on the build canvas are now collapsed by default, making complex dependency graphs much easier to follow at a glance.

• Collapsed by default: Group steps are now collapsed when you open a build, reducing visual noise and improving page performance on large pipelines.
• Expand and collapse all: A new button on the canvas lets you expand or collapse all group steps at once. You can also press G to toggle.

• Auto-expand on failure or input: Groups containing failed steps or steps waiting for user input are automatically expanded, so you never miss something that needs your attention.

You can still expand or collapse individual group steps by clicking on them.

You can now toggle case-sensitive matching when searching through job logs on the new build page. Click the Aa button in the log search bar to switch between case-sensitive and case-insensitive search.

The Buildkite MCP Server now sanitizes all tool responses to protect agents from prompt injection attacks. Build logs, pipeline names, commit messages, and annotations are passed through a multi-stage sanitization pipeline before reaching the agent — filtering invisible characters, stripping control sequences, sanitizing HTML, and neutralizing LLM delimiter tokens.

The list_builds tool no longer requires a pipeline_slug. When omitted, it queries across the entire organization, making it easier for agents to find failing builds without needing to call the tool once per pipeline.

When the Buildkite API returns an authentication error, the MCP server now surfaces it as a proper 401 response rather than a generic tool error. This means MCP clients and agents can correctly prompt you to re-authenticate instead of failing with a cryptic message.

A new --max-log-bytes flag (and BKLOG_MAX_LOG_BYTES environment variable) lets you cap how much log data the server downloads per request, defaulting to 100 MB. This gives you more control over memory consumption when working with large pipeline logs.

These improvements apply to both the open-source MCP server and the Remote MCP server.

The Buildkite Remote MCP server now rate limits on a per-user basis, so one person can't chew through your organization's entire API quota.

If you've been hesitant to roll out the remote MCP server broadly, this should help. Each user gets their own limit of 50 requests per minute, so you can invite your whole team to connect their AI coding assistants to Buildkite without worrying about one heavy user blocking everyone else.

There's nothing to configure, per-user limits apply automatically. If someone hits their limit, only their requests are throttled. Everyone else carries on as normal.

For more on API rate limits across Buildkite, see the Remote MCP server limits documentation.

Organization administrators can now view the service quotas that apply to their organization directly in Buildkite. Head to Settings > Quotas to see your actual limits, broken down by product area.

Each quota shows the effective limit for your organization. A Custom badge indicates a limit that differs from the default for your plan, and an Exceeded in last 24h badge flags any quotas your organization has hit recently.

If you need a quota increased, contact support@buildkite.com or reach out to your Technical Account Manager.

For the full list of default limits, see the Limits documentation.

We've been busy making changes to the way the Buildkite CLI can authenticate against organizations. We've implemented some features, as well as improvements to security so folks can feel safer in giving the CLI assess to their Buildkite organization.

OAuth availability

The CLI can now be authenticated via OAuth, with permissions scoped within the user's own accepted access. The permissions can also be customized to meet your needs for CLI use.

A single auth family

We've introduced an auth command, with various subcommands, to ensure all things authentication can be found in a logical spot. whoami and use can still be used, for now, performing the same actions as their new subcommands, bk auth status and bk auth switch, respectively.

We've also implemented bk auth login, replacing configure add, and bk auth logout, a new command which will clear keychain credentials for the current authenticated organization, or all keychain configurations with the --all flag.

No more text-based tokens

The CLI, until now, has been writing API tokens to a config file, typically at ~/.config/bk.yaml, which is convenient but a pattern we've wanted to move away from. As of v3.32.0, we'll no longer write to this file, only read from it. API tokens will be encrypted and stored in the OS keychain exclusively.

The CLI will fall back to reading bk.yaml files, so if those are in use, or you wish to continue using them, you can, you'll just see a warning in the terminal when you do. If you do wish to store API tokens in your bk.yaml file, you can manually adjust the file;

organizations:
  my-cool-org:
    api_token: bkua_hunter28265989387498729792378

A lot to take in? Read the Buildkite CLI documentation

The Buildkite SDK now supports C#, starting in v0.8.0. You can define and manage your Buildkite pipelines programmatically in C#, with the same type-safe experience available in the SDK's other supported languages: JavaScript/TypeScript, Python, Go, and Ruby. The package is now available for download from NuGet.

Several of our most popular plugins now support GCP and Azure, making it easier to use Buildkite with your preferred cloud provider.

The secrets plugin fetches secrets and injects them as environment variables into your builds. It now supports GCP Secret Manager and Azure Key Vault, in addition to Buildkite Secrets.

The cache plugin stores and restores build cache between pipeline runs. It now supports Google Cloud Storage and Azure Blob Storage backends alongside Amazon S3.

The docker-cache plugin speeds up Docker builds by caching images between pipeline runs. It now supports Azure Container Registry as a caching provider.

The docker-image-push plugin builds and pushes Docker images to Google Artifact Registry and Azure Container Registry alongside its existing support for Amazon ECR and Docker Hub.

(New) The azure-login plugin authenticates your Buildkite agents with Azure using managed identity or service principal credentials. Pair it with our secrets, docker-image-push, or cache plugins to streamline your Azure workflows.

You can now save filtered views directly from the Suite Summary page. After configuring your filters, save them as a custom view that will appear in your suite navigation for quick access later.

This makes it easier to:

• Quickly access the summary trends you check most often
• Share a consistent, filtered view across your team
• Reduce time spent reconfiguring filters between visits

You can now set an expiry date when creating an API access token. Once a token expires, any API requests using it will stop working, so forgotten tokens don't become a security risk.

Choose from preset durations (1 day, 7 days, 30 days, 90 days, 1 year), pick a custom date, or select "Never" to create a token with no expiry.

Key details

• Expiry is set at creation and cannot be changed afterward. To extend access, create a new token.
• You'll receive an email 3 days before a token expires, with a link to create a replacement.
• Expired tokens are automatically deleted after a grace period.
• All existing tokens are unaffected and continue to work with no expiry.

For more information, see the API access tokens documentation.