Before anything else, thank you for the feedback you have shared on the Modern Build UI preview. We received a lot of it. We did not always respond to every thread, but we read and worked through every item. We hope you can see that influence in the path ahead.

We are updating the Build user interface (UI) for the first time in over a decade, because continuous integration has changed beneath us.

Some teams still ship with small, simple pipelines. Others run hundreds or thousands of jobs with deep dependencies and heavy parallelism. The build page has to work for both. Developers land here with limited attention and one goal, understand what happened and get back to green fast.

That is the heart of our product vision. Buildkite is the orchestration layer where pipelines run at the speed developers expect, deliver insights teams can trust, and surface the next best action to shorten the path from code creation to customer value. Our ultimate goal is coherence. When you understand what you are looking at and what to do next, you get back to building great software faster.

Classic earned trust through clarity. It made quick triage feel effortless.

As builds scaled, that clarity alone was not enough. Modern was born from that scale. We added clearer hierarchy, a sidebar for key context, and deep views like Canvas so you could rationalise large, complex builds. For those use cases, it is working. Adoption keeps rising in larger accounts, and many teams now rely on modern for their hardest pipelines.

But modern did not solve every job. Classic still feels simpler and faster on smaller builds, and some of its cues and layouts are better for quick reads. At the same time, parts of classic, once refreshed, add real value on large builds. The preview made that gap and opportunity clear.

The general availability (GA) version of the Modern Build UI is our solution to that. It keeps modern’s depth for complex builds, restores a simple default for triage, and makes the job of each view explicit. One build page that meets you where you are, then takes you deeper only when it helps.

Here is a short walkthrough of the direction:

https://www.loom.com/share/b6f08f358bf54d4cacdc729e6745d9be

Getting clearer on how to use the build page

GA is where we state a clear point of view on how the build page should work.

Start with the fastest path from red to green. If that is not enough, move into a deeper view built for the specific question in front of you. Each view has one primary job. That focus keeps the page simple under pressure, while still supporting hard debugging and performance work.

Our intended flow looks like this.

• List, default triage. Answer “what failed and what do I do next?” in one scroll. Open the right log fast, with annotations kept in band, plus job and step annotations that call out what matters at the point of failure.
• Table, analysis at scale. For big builds, filter and sort by status, duration, name, or agent to spot patterns and outliers without losing your place.
• Canvas, structure. For complex or unfamiliar pipelines, use the dependency graph to understand order, fan out, and where failures sit. The sidebar only lives here, because this is where extra structure helps.
• Waterfall, timing. When the job is speed, use the timeline to find wait time, slow steps, concurrency gaps, and the critical path.
• Tests tab, test outcome summary. When you need to know which tests failed and whether they are flaky, switch to Tests for grouped results and reliability at a glance. Jump to the job for logs, or to Test Engine for suite trends and remediation.

GA also tightens the shared foundation across every view.