We're excited to announce Vitest support for our Buildkite JavaScript Test Collector, expanding our test framework coverage for Test Engine.

With Vitest support in the JavaScript Test Collector, you can now:

• Collect test results from your Vitest test suites
• Track test performance and flakiness over time
• Benefit from Test Engine's powerful analytics and insights
• Automatically quarantine flaky tests

To begin using the Test Engine with Vitest, follow the instructions in our JavaScript Test Collector documentation.

The new build page has been updated with a bunch of improvements that now make it easier to focus on what matters, move faster through your builds, and tailor the interface to suit how you work. Whether you're reviewing a failed test, scanning logs, or debugging pipeline performance, these updates help streamline the experience across pipelines of all shapes and sizes.

With so many changes landing, we thought why not record a video to walk you through them all.

Key changes

New build header

We've redesigned the build header into a more condensed version—reducing noise on the page, and helping to draw more attention to the things that need actioning: failed steps and annotations. With this revision, the build status is also now always visible regardless of how you've configured the build interface.

Overview tab

There's a new overview tab that contains high-level build information—such as the commit message, build creator, build trigger and much more.

Annotations tab

The annotations have been moved into a top-level tab, making them easier to find and use.

Configurable default view preferences

You can now set a personal default view preference—allowing you to control where you start when opening a build. This can be applied globally or customized per pipeline.

Collapsible sidebar

The sidebar can now be toggled open or closed, giving you more control over the layout when diving into a job or viewing other parts of the build.

Step search in the sidebar

We've added a new search, allowing you to find and jump to steps quickly across your build.

Keyboard shortcuts:

• S: Open search box
• Enter: Open the step
• Shift+Enter: Focus on step in current step view

Jump to failure

The jump to failure action has moved into the sidebar, making it possible to cycle through failures wherever you are in the build.

Other notable improvements

• Log performance: Improved rendering performance and added support for searching within collapsed sections.
• Canvas unblock UX: Clicking an unblock step now opens the unblock dialog directly.
• Smarter canvas focus: For large pipelines that don't fit neatly on the canvas, we now focus on the first failure—or the first step if all steps pass.
• Canvas zoom constraints: Zoom levels are now constrained to prevent unreadable dependency graphs.
• Resizable table columns: Table view now supports column resizing for improved readability of long job labels.
• Responsive improvements: Improved layout behavior on smaller screens to avoid overlaps and horizontal scrolling.

Thanks again for all the feedback which continues to help us shape each release.

We've added support for GitLab.com commit statuses to Buildkite Pipelines ✅

Buildkite can now send status updates to GitLab for each build state (scheduled, started, running, passed, failed, blocked, canceled, skipped). Status updates appear on commits and merge requests in GitLab. These link back to the corresponding Buildkite builds.

Turn this on today by connecting to GitLab.com:

Then update your favorite pipeline's repository settings page to turn on commit status reporting ✨

For more details, see our GitLab documentation.

You can now send Slack notifications from Buildkite Test Engine!

Slack notifications can be triggered when a test state changes, or when a test label is added or removed.

Additionally Slack notifications can be filtered to only tests owned by particular teams.

Read more about Test Engine Slack notifications.

The Flaky Resolution feature is being deprecated and will be removed for all users in the coming week.

You can continue managing flaky tests by removing the flaky label. You can review all currently flaky tests via the Tests page, by filtering for tests with the flaky label.

Learn more about flaky test management.

The My Assignments feature is being deprecated and will be removed for all users in the coming week.

Users can continue to review tests owned by their teams using the filtering functionality on the Tests and Flaky tests pages.

As part of this change, the Flaky Summary Mailer will also be updated to show the flakiest tests owned by your team, rather than those that were previously assigned.

You can now send webhooks from Buildkite Test Engine!

Webhooks can be triggered by the following events:

• Test state changed
• Test label added or removed

Additionally webhook events can be filtered to only tests owned by particular teams.

Read more about Test Engine webhooks.

You can now save your favorite test filters in Test Engine for quick access.

The new filter bar in the test list lets you add filters using execution tags and test labels. Once you've set up a view you like, click Save to name it. Your saved filters will then appear as a view in your suite navigation for easy access.

Buildkite Portals are user-defined GraphQL operations exposed via authenticated URL endpoints — offering a new, secure way to access the Buildkite API.

Designed with machine-to-machine operations in mind, Portals are not tied to user-owned access tokens. Instead, they use ephemeral, scoped tokens that can only perform the operations defined in an approved GraphQL document.

Key benefits of Portals include:

• Scoped access — Tokens are restricted to the exact operations defined by organization admins. This enables fine-grained, least-privilege access to your Buildkite data.
• Ephemeral tokens — Tokens are short-lived and single-purpose, ideal for secure machine-to-machine communication.
• User-invoked flow — Optional interactive flows allow users to generate tokens on-demand, similar to OAuth.
• Userless authentication — Tokens are not tied to any individual user, avoiding disruptions if team members are removed.

Getting started with Portals

Portals can be created by administrators from organization settings page. Each portal is assigned a unique endpoint with the following URL structure: https://portal.buildkite.com/organizations/{organization.slug}/portals/{portal.slug}

Portals support passing variables to enable dynamic operations and offer multiple authentication mechanisms for flexibility and security.

For more information, see the Portals documentation.

Buildkite Test Engine now supports test splitting (smart bin packing for faster CI) and auto-quarantining (automatic detection and isolation of failing tests) for Python PyTest suites.

• ✅ Cut down your critical path time.
• ✅ Keep flaky tests from blocking your pipeline.
• ✅ Spend less time on manual triage.

To get started, install the Test Engine Client to:

• Automatically split tests evenly across parallel jobs.
• Quarantine unstable tests based on customizable heuristics.

For full setup instructions, see the Test Engine docs.

Within Linux Hosted Agents, the Docker binaries have now been updated. These new versions are as follows:

• Docker Client -> From 25.0.4 to 27.3.1
• Docker Buildx -> From 0.13.0 to 0.22.0
• Docker Compose -> From 2.24.7 to 2.31.0

You can now label your tests with Buildkite Test Engine!

Labels allow you to:

• Organize tests to be more meaningful to your team and organization.
• Categorize tests, and therefore, can be used to filter tests within Test Engine.

Labels may be applied to or removed from tests:

• Manually through the Buildkite interface.
• Automatically through the automatic quarantine or test execution tags features.
• Using the REST API.

Start labelling your tests with Test Engine today.

We're extending the preview period for our new build page beyond the originally announced April 24th date. This extension gives us time to incorporate your valuable feedback and implement several significant enhancements before making it the default experience.

Why we're extending

Your feedback has been instrumental in shaping the new build page. We're working on performance optimizations and feature additions based directly on your input, with some substantial improvements in the pipeline.

Rather than rushing these changes, we want to:

• Complete the implementation of key performance improvements
• Incorporate requested features that enhance your workflow
• Ensure a seamless transition when the new experience becomes the default

What's next

We remain fully committed to the new build page with its enhanced navigation, powerful table views, improved build management, and better annotation support. If you haven't tried it yet, we encourage you to opt in through the button on any build page.

When our next wave of improvements is ready, we'll announce a new deprecation timeline for the classic build page, giving everyone ample time to adjust to the changes before they become standard.

Please continue sharing your feedback at support@buildkite.com - it directly influences our development priorities.

You can now add custom tags to your tests — unlocking a whole new dimension (literally) of insight and control.

Whether you want to tag tests by the infrastructure they run on, the services they touch, or framework versions they depend on, custom tags let you define what matters — and then slice your test data by those attributes.

🔍 Find root causes faster

Spot patterns in failures and slowdowns by breaking down your suite along your real-world dimensions — like container image, compute pool, or dependency version.

📊 Insights tailored to your stack

Move beyond generic test metrics. Aggregations by custom tags give you visibility into the things that actually cause pain in your CI.

💸 Drive cost and performance optimizations

Use tags to identify high-cost, slow, or flaky tests by environment — and target improvements where they’ll have the biggest impact.

Start tagging your tests with Test Engine today.

The Changelog, ChangelogAuthor, ChangelogConnection, and ChangelogEdge types have been removed from the GraphQL API.

Please use the changelog Atom feed (https://buildkite.com/changelog.atom) instead.

Buildkite has joined the the GitHub Secret Scanning Program to enhance security for your API tokens. This program helps detect and alert us when a Buildkite API access token is leaked in a public GitHub repository.

What happens when a token is detected:

• For tokens found in public repositories or npm packages: GitHub immediately notifies Buildkite, and we automatically revoke the affected token to prevent unauthorized access. The token owner and organization admins receive notifications about the incident.
• For tokens found in private repositories with secret scanning enabled: Repository admins and the committer are alerted directly through GitHub's interface, where they can view and manage the detected secrets.

FAQ's

Do I need to enable anything to get this protection?

• For public repositories, protection is automatic with no configuration needed.
• For private repositories, repository administrators need to enable GitHub Secret Scanning.

What types of Buildkite tokens are protected?

• Currently, only Buildkite API access tokens

How will I be notified if my token is revoked?

• The owner of the token and the admins of the associated organization will receive an email from Buildkite.

What should I do if I receive a notification about a leaked token?

• Generate a new access token for your Buildkite user account.

It is now possible to pause individual Buildkite agents. Pausing an agent is similar to stopping an agent, but unlike stopping, a paused agent remains running and can resume work later on.

Pausing an agent is a useful alternative to stopping an agent, especially when resources are tied to the lifetime of the agent, such as a cloud instance configured to terminate when the agent exits. By pausing an agent, you can investigate problems in its environment more easily, without the worry of jobs being dispatched to it.

Some examples of maintenance operations that could benefit from pausing an agent include:

• pruning Docker caches
• emptying temporary directories
• updating code mirrors
• installing software updates
• compacting or vacuuming databases

You can pause agents in either the UI, GraphQL API or Rest API. Paused agent counts will be reflected in the platform.

To fully benefit from pausing, we recommend upgrading your agents to the latest released version.

See Pausing and resuming agents on Buildkite Docs for more information.

Buildkite now supports setting commit statuses on GitLab self-managed instances. This integration enables real-time status visibility in merge requests and can block merging until builds pass.

You can configure commit statuses today from your organization's repository providers page:

https://buildkite.com/organizations/-/repository-providers

Look under API Settings for configuration instructions:

Then go to your favorite pipeline's repository settings page to turn on commit status reporting ✨

You can now see the source IP ranges used by your Buildkite hosted agents in your cluster.

We're introducing expiry timestamps for agent registration tokens in response to customer feedback around security compliance and token lifecycle management.

You can now set an expiry time when creating tokens via both GraphQL (expiresAt) and REST (expires_at) APIs. The timestamp must be in ISO8601 format (2025-01-01T00:00:00Z).

This change enables automated token rotation through API integration, replacing the previous manual rotation process for long-lived tokens.

Important details:

• Existing tokens will continue to work without expiry
• Expired tokens will prevent new agent registrations but won't affect currently connected agents
• The UI will display tokens as "expired" after their expiry date
• Expiry dates cannot be modified after token creation
• There is no maximum expiry duration but a minimum of 10 minutes in the future is required

Below is a GraphQL example showing the creation of a token with an expiry.

mutation createToken {
  clusterAgentTokenCreate(input: {
    organizationId: "",
    description: "a token with an expiration",
    clusterId:"",
    expiresAt: "2026-01-01T00:00:00Z"
  }) {
    tokenValue
  }
}