Extending the opt-in period for our new build page

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
  }
}

Since turning on the new build page for everyone, we've been listening to your feedback and working hard to make improvements. Thank you for bearing with us. We're excited to announce a number of new changes that we hope you'll find valuable, with more on the way ahead of deprecating the classic build page on April 24, 2025.

Performance Improvements: faster Canvas and Table

To make the page faster for you, we’ve added virtualisation to the canvas and table views – rendering only what needs to be rendered, making a significant improvement for builds with hundreds or thousands of steps. On our backlog is to give the same treatment to the sidebar.

Persistent sidebar between builds

Keep your sidebar consistent as you navigate through builds now that we persist collapsed states in the build page sidebar (ie. Failed, Running, Passed). With large builds showing hundreds of passed steps you don't need to see, once you collapse Passed steps they'll stay like that on all consecutive builds.

Get the same view by default on your builds

Going between builds is now better as your preferred view persists. Your personal selection of "Canvas", "Table", or "Waterfall" is remembered as you navigate across builds. These views are now consolidated into a single "Steps" tab where you control which visualization you'd like to use.

Many people gave us feedback about situations where the canvas or table weren’t particularly useful and now they’ll be able to stay on their preferred view.

More intuitive filtering

We’ve moved step filtering out of the sidebar and into the “Steps” view to allow users to filter down their pipeline steps whilst continuing to have the overall context of the pipeline. This lets the sidebar remain a navigational aid even when narrowing down on failed steps.

An added benefit: debugging some job slowness using the waterfall view? Waterfall now supports job-level filtering.

Less noise in the sidebar

To make the sidebar more useful, we’ve improved the way we surface the relevant jobs based on the current state of a step. Here’s an example of this in action when viewing a build with a failing step with a high number of parallelism.

You’ll see how we present the failed job, but we initially hide the passed jobs.

We have also changed the way we display failed steps, by giving them a slight red background. Making it easier to see failed steps in your pipeline of the sidebar. Particularly useful when using the Pipeline view.

What's next?

We are still looking at opportunities to improve the page and make migration from the classic build UI easier. In particular we are considering improvements to annotations, layout and information architecture as well as unblocking block steps.

Customers often need to send custom slack or email notifications when steps fail. If an important build or deploy step fails, then someone needs to know about it. But, this hasn't been the simplest process until now.

You can now reference a step's information (id, key, label, type, state and outcome) in conditionals by prefixing with step. (such as step.id). This is particularly useful when you need to notify someone as soon as a step fails. See detailed descriptions of these values in our docs on conditional variables.

Here's how simple it is now:

steps:
  - command: false
    notify:
      - slack:
          channels: ["#engineering"]
          message: "Important step failed, please fix."
        if: step.outcome == "hard_failed"
  - command: sleep 1000

Previously, the recommended solution required conditionally uploading a new step to handle notifications:

steps:
  - label: "Fail"
    command: exit 1
    key: "fail"
  - label: "Run regression only if fail check is failed"
    depends_on: "fail"
    command: |
      if [ $$(buildkite-agent step get "outcome" --step "fail") == "hard_failed" ]; then
         cat <<- YAML | buildkite-agent pipeline upload
         steps:
           - label: notify"
             command: notification.sh
      YAML
      fi

For quick reference, options for step.outcome are neutral, passed, errored, hard_failed or soft_failed. step.state can be one of ignored, waiting_for_dependencies, ready, running, failing or finished. step.type exposes the step's type such as command or trigger. Step key and label are user defined values.

This new syntax works with all notification types (Slack, email, webhooks, etc.) and can be combined with other conditions using standard operators (&&, ||). Each step's notification can only reference its own outcome - you can't reference other steps' outcomes directly in the notification conditional.

Notifications are sent immediately when the step completes with the specified outcome, providing faster feedback when issues occur.

We are happy to announce a small but significant update to our Favicons, bringing a fresh look and improved functionality that enhances your experience with our platform.

Our favicon journey began over a decade ago with the introduction of our vibrant rainbow dynamic Favicons. These icons not only indicated build statuses but also became trusted companions for developers. Since then they’ve gone relatively untouched, so why change now?

There were a few other reasons our rainbow icon suite fell short but overall many of you were experiencing a few things:

• Confusion and trouble with keeping track of multiple tabs with the abrupt color changes
• Falling short of modern accessibility standards, especially for those with visual impairments such as color blindness
• Our core icon was very hard to see with dark theme enabled browsers (dark mode didn’t even exist back when the initial Favicons were created)
• Low resolution and pixelated Favicons on modern monitors

So what’s changed? Here’s a little summary of all the improvements!

Icon-Based Statuses We’ve introduced micro icons for statuses, making it easier to navigate and reducing confusion.

Consistent Favicon Color The core favicon remains the same, ensuring familiarity and visual consistency across multiple tabs.

New Status Variant There’s a new kid in town - pipelines that are blocked now have their own look helping you know when a build requires attention.

Dark Mode Support Our Favicons now look fantastic in dark mode, ensuring visibility and aesthetic appeal across different themes and devices.

Modern Formats and Compatibility SVG and PNG Compatibility: Favicons are now primarily in SVG format for sharp visuals, with PNG fallbacks for older browsers. Also we’ve unlocked bolder and more vibrant colors for those with supported devices by utilizing OKLCH color types.

Additional Improvements

• We’re also introducing a new favicon for our Docs site, making it easily distinguishable from the app.
• Updated pinned and docked icons for better representation across platforms.
• Improved color themes in Safari to match our app more closely.

A lot of you have already noticed the change and we’re absolutely loving how impactful these small changes have been for you. As always, we love to hear your feedback and thoughts, so please let us know what you think at support@buildkite.com.

We’re kicking off 2025 with powerful improvements to make your Buildkite life much easier. Based on your feedback, we’ve shipped several key enhancements that make debugging faster, collaboration smoother, and pipeline management more intuitive 🚀

Better large log viewing experience

We’ve introduced log line grouping and direct linking within the dedicated log interface of the build page. If you're viewing the dedicated log page because your large logs are being truncated in the build page – you now get the same benefits of viewing logs within the build page.

Logs follow group collapsing and allow you to copy URL links to direct log lines, improving the developer experience. This allows for precise debugging and easier collaboration when sharing logs.

Faster build browsing with user and date filters

We’ve added additional filtering capabilities on the pipelines build page. You can now filter and search for builds by user and by date. This makes troubleshooting and locating colleagues' builds much easier.

Easier troubleshooting of your build's steps

This used to be a secret page, which is why we're so excited to give this to everyone. Whilst on the new build page, you can view a pipeline's original steps and any uploaded steps as YAML directly on the Summary tab, under Step uploads. Prior to this change, troubleshooting the steps of a complicated build could proove challenging. This helps teams better understand how a build was defined and executed within each step of the build.

Allowing users to view org rules via Terraform

This change relates to a customer preview feature, Rules, for creating exceptions to Cluster security boundaries. Previously, a Buildkite organization administrator would need an API access token with the GraphQL scope to view the organizational rules using Terraform. This would prevent Buildkite organization members (non-admin users) from viewing rules through the GraphQL API, causing a conflict within the Terraform state file.

Since this change, non-admin users can view their organisation's rules the Buildkite GraphQL API, which allows users running Terraform Plan and Terraform Apply to apply Buildkite organization rules using the Buildkite Terraform provider without any state conflicts.

Tighter security posture by limiting the lifetime of OIDC tokens

Previously, we did not enforce lifetime limits on OIDC tokens. This was raised by many customers as a good opportunity to provide more constraints. Since this change, OIDC tokens now have a maximum lifetime of two hours. Read more on how to use OIDC tokens.

Test run scheduled pipelines

We know testing and validating scheduled pipelines can be tricky based on customer feedback. With this new button, you can now test your configured scheduled pipelines using the set environment variables. Do this by selecting the “Run now” button saving saving your scheduled pipeline.

We're thrilled to introduce Cluster Insights - your new command center for CI performance monitoring. Available now for Enterprise customers.

Cluster Insights delivers real time visibility into your CI infrastructure with powerful metrics that matter. At a glance, see if your teams are facing bottlenecks, track system performance, and make data-driven decisions about your CI resources.

For platform engineering teams balancing cost optimization with developer productivity, Cluster Insights provides the metrics you need. Monitor key performance indicators, identify trends, and ensure your CI infrastructure scales with your team's needs - all from a single, intuitive dashboard.

Key metrics include:

• Queue Wait Time: Track job start delays in real time
• Queued Jobs Waiting: Monitor queue depth and volume trends
• Agent Utilization: Optimize your CI resource allocation
• Job Pass Rate: Identify stability issues before they impact teams

Drill down from organization-wide views to individual queue performance, with detailed p50, p75, p90, and p95 wait time breakdowns to help you spot and resolve bottlenecks. Read our guide to Cluster Insights in the docs for more guidance on how to use these insights to improve developer productivity.

We're excited for the future and anticipate adding expanded insights across both build performance and agent-level metrics, creating an even more comprehensive CI observability solution.

Note: Metrics are only available for agents in clusters. Running unclustered agents? Contact us at support@buildkite.com to discuss cluster migration strategies.

We'd love to hear your feedback, so please let us know what you think at support@buildkite.com.

The build page has been completely reimagined to support modern software delivery at any scale. From light weight test suites to complex infrastructure deployments, this new experience adapts to your workflow while maintaining Buildkite's signature flexibility. The redesigned interface brings powerful navigation through a new sidebar and powerful table view, making it easier than ever to understand and troubleshoot your builds.

Opt in now on the build page! The new build page will become the standard experience on April 24, 2025.

TLDR:

• The new build page is here - opt in and check it out!
• Find everything faster with the new sidebar and a Table view that shows all your jobs
• A new job details drawer available on every page. You can affix to the bottom, right or docked in the center.
• Your annotations now live in the Summary tab, just one click away in the sidebar
• The existing views still work just like before

Enhanced Navigation and Visibility

The new build sidebar transforms how you navigate complex pipelines, providing a state-based view of your build steps that makes it easy to understand progress at a glance. Quick filtering and grouping by state helps you focus on what matters, while intelligent nesting of groups, parallel, and matrix steps keeps everything organized.

The new sidebar listing all steps, grouped by state with additional filters.

We've also introduced an adaptive layout that puts you in control, showing the highest priority items at the top. Immediately see blocked or failed steps at the top of your sidebar. Position the step log drawer on the side, bottom or center of your screen and resize it to your needs. We’ll remember your settings for convenience.

A new table view is perfect for power users looking for all queue and agent information across all jobs in one place. Clicking on column headings sorts by that column for easy browsing.

The new table view showing all jobs in a build.

Easier Build Management

Understanding triggered pipelines is now seamless with trigger steps endowed with their own step drawer details. Monitor downstream builds directly from the parent pipeline without leaving the page - perfect for microservices architectures and fan-out CI/CD workflows where one pipeline kicks off many others.

See the status of a triggered build in the trigger step drawer.

Retries are now easier to track and manage with enhanced visibility throughout the interface. Retried steps are clearly indicated in the sidebar, with hover tooltips for quick navigation between attempts. The step drawer provides a consolidated view of all retries, letting you jump between specific executions effortlessly.

Retried steps are more easily identified in the sidebar, with all jobs available in the logs drawer.

Our customers are often pushing the boundaries and scale of software delivery, so we’ve put in deliberate effort to improve the build pages’ ability to handle large scale builds. This is an ongoing journey, but we’re happy to report faster page loads for large scale builds of 500 to 10,000 steps.

Annotations and more on the Summary tab

Annotations have been moved to the Summary tab, with links to them from the sidebar. This supports annotations in the style of a 'banner' with context of the overall build.

Annotations linked in the sidebar and available on the summary page.

A crowd favorite, we know many customers also use annotations to give context on individual steps, such as neater build outputs or Terraform plans. Which is why we intend to provide additional annotation types in the near future, such as a step annotation with the annotation displayed alongside step logs.

You're now also able to view all the step definitions of your build in YAML. Both initial steps and uploaded steps are available on the Summary tab, under 'Step uploads'.

Getting Started

1. Look for the "Try New Build Experience" button on any build page
2. Toggle between new and classic views anytime during the opt-in period
3. Share your feedback to help us refine the experience at support@buildkite.com
4. Read our docs page on the new build page to read about key features

Note: The classic build UI will be deprecated in two months on April 24, 2025, at which point all users will be automatically upgraded to the new experience.

Built for the Future

This redesign lays the foundation for exciting capabilities coming to the build page in the future. Here are some improvements we're planning:

• Enhanced personalization options to remember your preferred default view settings
• Improved table view with better customization
• Collapsible sidebar for maximizing screen space
• Step-level annotations for more granular build insights
• Multi-log viewing to compare outputs side by side
• Collapse groups of steps on the canvas to optimize rendering
• Unblock builds with one click
• Critical path analysis in the canvas

This new build experience is just the beginning. We're committed to making Buildkite the most powerful and flexible platform for software delivery, and this update sets the stage for even more improvements to come.

Please reach out to support to let us know your feedback at support@buildkite.com once you've tried it. We're keen to ensure this new update suits the wide range of customers and use cases for which Buildkite is known.

The Retry failed jobs button now includes eligible failed jobs from any synchronously triggered builds. This change eliminates the need to manually retry jobs in triggered builds one by one, in favour of a single click.

Based on customer feedback, this enhancement significantly improves the developer experience when working with parent pipelines that contain multiple trigger steps. This is particularly valuable for complex pipeline configurations using trigger steps to break down workflows.

This update streamlines the process of getting your pipelines back to green, making it easier to maintain and manage sophisticated build workflows.

We have rolled out a new fix for pipelines that have hanging jobs.

If you are using test splitting queues such as Shopify's open source tool ci-queue (https://github.com/Shopify/ci-queue) at scale, you may have noticed that some jobs are hanging around and causing your builds to take longer than expected.

There is now a new agent cli command to cancel these pesky jobs to improve your build times.

To force cancel all jobs in a step you can run the following from any job within the target build:

buildkite-agent step cancel --step <step_key> --force

In this kind of situation you may have a pipeline that looks like this:

steps:
  - command: test_reporter.sh
    key: reporter
  - command: test_worker.sh
    key: workers
    parallelism: 500
    soft_fail: true

In this pipeline the workers are responsible for running the tests but the outcome of the tests is reported by the reporter step. The outcome of the workers in Buildkite is not relevant to the build outcome. When a step is marked as soft fail Buildkite still waits for all jobs to finish before marking the build as passed. This can cause the build to take longer than necessary. To fix this you can add a step to cancel the workers after the reporter step has finished.

steps:
  - command:
      - test_reporter.sh
      - buildkite-agent step cancel --step workers --force
    key: reporter
  - command: test_worker.sh
    key: workers
    parallelism: 500
    soft_fail: true

If you find this cancels too quickly, leaving agents unable to upload logs and artefacts, you can set a custom a grace period with the --force-grace-period-seconds flag. This will allow the agents to finish their work before being cancelled.

steps:
  - command:
      - test_reporter.sh
      - buildkite-agent step cancel --step workers --force --force-grace-period-seconds 10
    key: reporter
  - command: test_worker.sh
    key: workers
    parallelism: 500
    soft_fail: true

We've added step running durations to GitHub commit status step notifications.

When a step includes a :github_commit_status step notification the step running duration will be included in the commit status description on GitHub. The duration will show when the step is finished.

GitHub commit status step notifications can be configured in your pipeline.yml:

steps:
- command: build-the-thing.sh
  notify:
    github_commit_status: true

We've created a new Slack notification service for easier management of your Slack notifications. This new notification service requires only a single authorization for the entire workspace and replaces the need for multiple Slack notification services. See the documentation for enabling a Slack Workspace for your organization. Going forward, we recommend using Slack Workspace. Connecting this new notification service will not impact current implementations.

With this change comes:

• Build notifications now include mentions when triggering builds using an account with an associated email in slack workspace.
• Build notifications can be filtered to only trigger on the first failure with started_failing, rather than notifying on recurring failures. Using YAML, this is possible in the existing slack integration and the new workspace.
• Slack channels are now configured in pipeline YAML when using slack workspace.

We're excited to announce Playwright support for our Test Engine Client, to complement RSpec and Jest as supported test frameworks for test splitting. The client uses timing data obtained from your test suite to intelligently partition your tests across parallel agents, reducing the time taken to run them.

To begin using the client with Playwright, you can follow the instructions in the Playwright documentation in the Test Engine Client repository.

We have added support for AWS KMS signing of pipelines to the buildkite agent and integrated this feature into the Elastic Stack for AWS.

Customers can now easily enable signed pipelines in their elastic stack and take advantage of KMS to securely manage the keys. The settings used to configure this feature is as follows:

For more information on Signed Pipelines using AWS KMS see our documentation.