Get the jobs view back - keep the old experience enabled

Me and my team have been giving several tries to your new UI but still none of us is able to work with it as efficiently as with the old one, please listen to all the other negative feedbacks you have here. I think you still have many important UX issues that are still not addressed.

The most important thing for me is to get the job view back, the “workflow” view is simply not suiting my developer needs at all, and same goes for most of my team.

First and most importantly, the UI is inconsistent:

I don’t know what’s a workflow (and I don’t care, I just want to know if my build passed or not) and here I have to expand the “workflow” to understand why that one has been running for the whole night, but guess what: it has been canceled in the seconds that followed its creation and now it’s gonna stay in this “running” state forever! And there is a very similar problem for pending workflows as well, as you can see.

Second, not sure how that’s even possible, but we have on this page less information that we used to have on the “jobs” page while every “workflow” takes now more space on the page, I really don’t get the point here. For instance to access the code that trigerred the workflow, I have to expand the workflow, then click on the build and finally I can click on the PR / commit number, three clicks instead of one for a successful workflow.

Third, failed workflows automatically expand on the page, why is that? I don’t care that my colleagues run tests that failed, and since my workflow is always containing one single step you’re basically just flooding here, compared to the “jobs” view.

Also, I don’t really understand the left menu, I admit I didn’t use it much in the old version but now I’m never going to use it again: no more insights and no opportunity to switch between workflows and jobs if I ever wanted to. Now the new menu only contains things that I will never ever care of. I have nothing to do with pricing and I don’t think I’ll have to create new projects so often I need to have the button on every page I’m browsing (same for pricing actually). The “Old experience” button is actually the one I used the most here. Maybe consider putting actually useful links here or greatly reducing the size of the sidebar otherwise, because I think less than 1% of your users needs something else than the tests results, the others mostly care about tests results.

Last but not least, most of my colleagues wanted to send a negative feedback about the new UI but gave up because of the horrible UX on this website (forcing a 2FA on a feedback-related forum which uses OAuth is maybe a bit overkill, but also I have never seen a website that asks for a password right after an OAuth registration, I created a fresh account right now but have to click on “forgotten password” to connect to it)

Thanks for the efforts you’re doing, I like the style of the new UI, it’s a lot more modern and would love to use it but I just cannot use it efficiently as-is and will continue to camp on the “old experience” as long as possible


Thank you for this feedback! It’s incredibly helpful to have a summary of your experience with the UI. Your posts here is already being reviewed by the team.

As for this Discuss site, I hear you! I’m looking into changing the sign-in process (it’s under my purview). I didn’t know it asked for a password directly after the 2FA.

We really appreciate you taking the time to give us this feedback. We want folks to be successful on our platforms, and we’re listening to your feedback.

I’ll probably have one of my clients migrate off of Circle because of this. It’s unusable in this form. We need to see a list of builds, kind of like but tags are missing from the UI there.

Hi @gogaz,

Thanks for reaching out!

We took a look at your usage in our system to see if we could help with some of your feedback.

I don’t know what’s a workflow (and I don’t care, I just want to know if my build passed or not)

First of all, we hope you will take a look at workflows and explore a bit. Workflows are an integral part of how we’ve expanded as a product over the years and will allow you to split up your build to run faster. With your specific workflow (hope you don’t mind we took a look) it should save you lots of time. The majority of our users are harnessing that power and seeing great results.

For instance to access the code that trigerred the workflow, I have to expand the workflow, then click on the build and finally I can click on the PR / commit number, three clicks instead of one for a successful workflow.

Hmm, on this one the workflow should auto-expand if it failed, is running, or is most recent. So that first click you mentioned should not be happening in most cases. Is that a bug for you? Are they not auto-opening?

That said, it’s true we are missing the PR/commit link on that Pipelines page and hope to return that to you soon. We initially did not have that link via our new Pipelines API but it is present now.

Third, failed workflows automatically expand on the page, why is that?

Glad you asked! This is because the most common use case to look at CircleCI (encompassing >50% of job page views) is when the job is failed. We saw in many UX interviews that folks are, therefore, on the Pipelines page to dive into a failed run (their own or a coworkers). In order to reduce clicks and help them out, we auto-expand those pipelines.

I don’t really understand the left menu

Great feedback, we’re reassessing that.

no more insights

This is returning soon, bigger and better than before! But you can already access it now via Insights API, here.

Last but not least, most of my colleagues wanted to send a negative feedback about the new UI but gave up because of the horrible UX on this website

@thekatertot hears you (as do we!) and we’re looking into how we can make this site better. If you can bear it, please keep the valuable feedback coming.


Kate Catlin
Senior Product Manager, CircleCI

1 Like

I came here to post a message about missing key features and am glad to see @gogaz has put my frustrations with the new UI into words so well, including the tangental issues with signing up to Discuss to post the message in the first place. This was my third attempt to get through the confusing login process.

To back up what the question author has said, I don’t understand why the nomenclature has changed so dramatically from jobs to workflows. It has made the new user experience almost unusable for our team, since we developed our soft processes alongside Circle.

The first major thing we are missing is build numbers. We need to see build numbers as first class citizens in the UI, as we use those build numbers for collating code across repos when deploying. The build numbers are now hidden, it requires clicking around to find them.

The url patterns changing has also caused us headaches, though the redirects work ok (for now at least)

The other major feature missing is the ability to stop builds from lists. I don’t see where to do this in the new UI. I have to navigate to the job (workflow?) itself to stop the build, and from there it’s still in a dropdown menu.


These are very frustrating issues. As I said, we adopted the old CircleCI into our process over time, and this release has really pulled the rug from under us, slowing us down quite a bit.

Please advise if there are workaround for these issues that can save us clicks, or the estimated timeline for adding them back if that is on your roadmap.



Edit: I tried to include screenshots of the issues I mentioned, but I was only allowed include one. Please file under additional frustration.


Hi @nocarroll,

Thank you for your feedback!

Two follow-on questions:

  1. Where would you expect the Job number to be listed, if you were designing our system?
  2. Regarding this section…

Do you mean you want to cancel an individual job (within a workflow) from the top-level dashboard page? Or you want to cancel an entire workflow?

@nocarroll & @gogaz

Thank you for your feedback on Discuss. There were parts of the sign-in process here that were ugly and some that were broken. There is no longer 2fa enabled for community members, which means that you should be able to sign up w/GitHub or manually in a very simple workflow. Because of the platform, I can only control some aspects of this logic, but I hope this makes it easier for everyone!

We use workflows extensively and so we are glad they have not been dropped. However the old UI allowed them to be listed and that view has gone :frowning: In the last few days I have deployed a hundred or so workflows (various services and apps) each composed of several jobs spanning dev/uat/prd. The new UI is not good for this kind of work where a person must be across dozens of apps in various states of deployment across different environments. There is no visiblity into the the state of a system. The support for this kind of work was never that great but now it is worst. FYI it is also common for the status summary to not correspond to the actual status, see attachment (mac/chrome). Filtering on branches would help a lot. It would also help if we were also able to display pipelines ordered by the latest running job in each pipeline in addition to when the pipeline started

Another massive help for us would be have some control over the auto expanding of pipeline jobs

1 Like

Hi @Kate_Catlin ,

thanks for the quick reply.

  1. The job/build number used to be visible in each list item when viewing lists of jobs. I see a new number shown next to Pipeline, which seems to signify the pipeline number but I don’t know what that is. The job/build number, to me, should be available where this number is shown. Anywhere in this list as a top-level item that I don’t need to expand a row to see would be a huge improvement. Either in its own column or as part of a compound column. Perhaps more information could be added to the workflow column, since at the moment it’s just a link?

Do you mean you want to cancel an individual job (within a workflow) from the top-level dashboard page? Or you want to cancel an entire workflow?

I mean cancelling an individual job from the list of running jobs, shown above. I guess that’s the pipelines page? This action used to be available for every item in the list which was useful for us when merging feature PRs since multiple builds would often be started on a base branch, and we could kill off the older builds quickly.



Edit: I was reading back over the thread, and I think all my issues with the new experience are summed up in the topic title; we want to see jobs in Circle, not workflows or pipelines. We will have to migrate our process or migrate to another CI to get back to where we were in terms of speed.

1 Like

@nocarroll We do allow you to cancel workflows from the pipelines page, but from your screenshot it looks like you are not seeing those buttons. We just deployed a change that I’m hoping will make those appear. It appears that you only have one job per workflow. So cancelling the workflow should be effectively the same thing as cancelling a job for you. Please let me know if you don’t see those buttons in the actions column on the right and we will continue to troubleshoot… Cancel is indicated by and X icon, you can also rerun from failed and start


I hope this is the right place, because I share the frustrations! I need to see what commit triggered! Relying on comments is silly if there is a massive merge effort going on.
In addition, I have no idea how to see filtered parts of the workflows (jobs? not sure of nomenclature) . To illustrate, we have multiple sets of tests that are possible to be triggered in our workflows. How do I see all tests that were run in the last week? How do I see what was deployed to production and by whom, without checking every single workflow?


One more thing. What do I do with this use case:
User A: Commits and builds on branch a - three days ago
User B: Commits and builds on branch b - two days ago
User A: Merges branch a to master - 50 minutes ago.

Obviously all of this runs workflows, and mandatory steps. Now I have to figure out which one of these workflows was deployed to my test enviroment 10 minutes ago. How do I do that? Short of drilling down into each workflow, checking if it has deployment step, drilling into that and looking when that was, and also making mental math because it’s not Aug19th 3:44pm stamp, it’s 7 hours and 45 minutes ago.

I hope I don’t need to explain that we have more developers than 2, and there are more commits than 1 a week?

PS: discovered another gem. Relative timestamp that rounds to hours means that if we deploy within 10 minutes of each other, I don’t even see a way to tell what was first and what was second.


We also have the issues Oksana describes so well

Hi, I see the action buttons have been added. That’s great, one item off the list!

Thanks for the quick turnaround on that one.

1 Like

It so happened that we screwed up our test environment yesterday, and had to redeploy from various workflows, several times, and more than one person was working on it. We also did “rerun job with ssh” on deployment. That was a &*%$ing disaster!! There is NO way to find deployment URL, there is no way to tell who deployed what when. There is no way to even tell what is currently deployed (via circle, ie without querying our failing backend). Many swear words were said, and many links were posted in slack just to keep track which job ran when. How do I fix this?!!

1 Like

That sounds less than ideal. Let me check with the experts to see how we can make this better and get you some answers.

Hi @Oksana, you can view the running SSH jobs via the legacy jobs page at{vcs}/{org}/{project}/jobs. You can read more in this support article here: How to see running SSH jobs.

Additionally, we have an open feature request to Make CANCEL BUILD button visible in the UI, which you can comment and vote on for our PM’s to review.

Let us know if you encounter any issues accessing the legacy jobs page.


@oksana Thank you for this really specific feedback, it’s very helpful to understand how you are using the system. I will note these use cases as we continue to iterate on the product. In regard to the relative time issue, if you hover on the time in the start column (it takes a bit since it’s in the title tag) you can see the full timestamp.

1 Like

@oksana regarding seeing the commits, are you looking to see the commit SHA in the main pipelines view?

1 Like