I just opened CircleCI and received the new pipeline view, and thought I’d let you know my thoughts on it. My usual workflow for checking circle-ci is when a build fails. Let’s walk through it as an example:
Old UI:
Open pipelines page (I normally have this open in a pinned browser tab at all times)
See which pipeline failed, why it triggered, and whether it took too much time (indication that this is a flaky hang, not a real build issue. We have those regularly, but haven’t managed to reproduce them outside CircleCI).
If it’s a flaky hang, click the rerun from failed icon. (Done, and since I have auto-expand enabled, in a single click)
If it’s not a flaky hang, click the relevant failed job. (Since I have auto-expand enabled, this is the first click)
If it’s a test failure, click on the “Tests” tab (A useful feature would be that CirceCI would auto-open the “Tests” tab instead of the “Steps” tab if there are failing test results). And see which tests are failing. Then navigate back to the pipelines overview. (Done in three clicks)
If it’s not a test failure, click the step, highlight the output, and paste it in VSCode (because of the long standing separate issue that log lines don’t render in CircleCI, but can still be selected and copied)
Navigate back to the pipelines overview (so my pinned browser tab is ready for the next iteration)
Read the log in VSCode and see what’s wrong. (Done in three clicks, and a copy-paste).
In summary, in the new UI, I’m most often finished in one, three or four clicks, and the level of information shown on the screens is in general appropriate for the level of nesting of the screens. When more information than might be expected is available (e.g. trigger, duration) that is useful information at that level.
New UI:
Open pipelines page (I normally have this open in a pinned browser tab at all times)
Click the row of the failed run. (This one click is now always needed). It automatically opens the first failed job (Great idea! This actually saves me a click sometimes)
Check if the duration indicates a timeout. If so, click the rerun from failed button. Then click the back button to navigate back to the pipeline overview. (Done in three clicks whereas previously I’d be done in one click)
If it wasn’t a timeout, and the failure was not a test failure, it’s likely that the log is already open in the right panel. Copy-paste it to VSCode to read it. Click back to go back to the main overview page. (Done in two clicks whereas previously this’d be three clicks. And a copy-paste)
If it was a test failure, click the “Tests” tab and investigate what’s wrong, then click back to the overview page. (Done in three clicks, same as previously)
Summary
Overall, my workflow became simpler in more complex cases but more complex in simpler and more common cases. The UI became less gradually layered and I think it is harder to comprehend than previously, but some choices were clever (auto opening the failed job) and compensate.
Suggested changes
Personally I suggest these changes to the new UI:
Duration should be put back in the overview row
Trigger reason should be put back in the overview row
Rerun / rerun from failed buttons should be put back in the overview row.
I think the two-rows-per-row table layout is harder to parse than the previous single row layout, but it does look nicer, so that’s a bit of a subjective thing.
The expand button in the overview row is completely wrong now since it doesn’t expand, but is one larger button with the icon, and also there’s not always an expand button (e.g. when not run) and then the icon column UI is wonky. This expand button should be removed entirely.
The auto open of failed step is great. But it can be improved. If there are test results uploaded, and some of those failed, open the “Tests” tab instead of the “Steps” tab.
I just thought of another improvement.
If you click the overview row for a workflow that’s currently paused on a hold step, it should immediately open that hold step.
Although a hold approve/cancel button in the overview row might be nice too.
I just realised that you can cancel from the hold icon in the overview row. It might be nice to allow approvals there too.
Did you guys actually roll out some changes based on these suggestions? I found out that the UI works better than expected, and I apparently missed some things. But then I went here to update my post, because I thought I made an error in the post, and I realised that the UI actually changed since I made this post.
(The other explanation for the changes might be weirdness such as browser caching)
The rerun icons are accessible from the overview row once again, but you have to click the expand button / icon in front of the row. The expand icon is now always shown, even for non-runs.
I’m pleasantly surprised by the new UI given the recent improvements. However there’s still an issue. The “rerun from failed” button is accessible through the main overview when you click on the run icon. However, it’s kind of useless, as nothing in that UI shows which job failed. And that’s essential information for me to know whether I can just click “rerun from failed”, or need to investigate first.
Today the run icon dropped all functionality and seems to simply click through to the row. This is a serious downgrade in functionality for no apparent reason.
The UI has been completely overhauled once again, and I like it mostly, but now there’s something really dumb. When a pipeline run is in a hold step, the icon in the left column (pipeline runs) still shows the in-progress icon. This means that you cannot see for which runs you must do something. You have to click through all in-progress runs, to see which are genuinely running, and which are on hold.
I had prepared a screenshot, but uploading here doesn’t work for some reason.
Having a lot of issues with the new UI. Really hard to use without getting angry, first I keep getting lost as it takes me to different graph views when I want to stay on the main workflow list for a repo.
The ordering of the jobs within a workflow run keep changing, making it hard to see what is going on. When in a job, looking at the step execution the scroll focus jumps around trying to pull to the bottom of the screen when I am looking at something at the top, very frustrating. If a workflow has a group, it shows as still running even after the workflow has finished.
I know change is hard and I will eventually get used to all the changes, but really preferred the old ui as it was a lot more reliable in my opinoin.
The new UI feels incredibly inconsistent. There now multiple versions of very similar pages that show more or less the same information but work differently. And it’s hard to guess how to navigate to any of them.
UI shouldn’t feel like a labyrinth. Honestly best would be to roll back to the 2025 UI and release something new only after it’s complete and cohesive.
Thank you so much for sharing your feedback. As you’ve noticed above, we’ve been able to address several of the items you’ve raised. We really appreciate you taking the time to share your thoughts as we continue to improve this experience.
Regarding the hold step, if you could DM me the screenshot, I’d love to take a closer look.
Adding a few more issues I’ve run into with the updated view, mostly around filtering/caching and missing live updates:
1. Saved presets serve stale/cached results
Saving a preset (e.g. project + “Last 7 days”) and then loading it later shows a cached list of pipelines — it doesn’t fetch fresh data. If I then re-click the same “Last 7 days” filter manually, that triggers a fresh fetch and new pipelines show up. Applying a saved preset should trigger an immediate fetch, not serve whatever was cached when it was saved.
2. No live/auto-refresh for the pipeline list
With filters applied, pushing a new branch kicks off a new pipeline, but it never appears in the list — I have to re-apply the filter or hard-refresh the browser to see it. Either poll/refresh the list automatically while it’s open, or at minimum add a visible “new pipelines available” / manual refresh affordance so it’s obvious data is stale.
3. Approvals should be actionable from the pipeline list, not just inside pipeline details
Related to what’s already been flagged in this thread (hold-step visibility/approval from the overview row) — approvals for held jobs should be accessible directly from the accordion on the pipelines list, without drilling into the pipeline/workflow details. Right now getting to an approval means navigating in, which adds unnecessary clicks for something that’s often just a “yes, go ahead.”
Together these make the list view feel unreliable as a “leave it open in a pinned tab” dashboard, which was one of the strengths of the old UI.