It’s not super critical or anything, but it was nice when the UI would pick up changes automatically and display them. The actual build/job screen displaying each step updates just fine, in realtime as the job progresses - so seems to just be the jobs dashboard. I have also tried FireFox and it’s the same there.
I’m trying to report this also… I have the same issue. UI won’t update. I have to refresh. This is a MAJOR issue to me, since I’ll often have multiple builds in progress, and waiting for some to finish before I move on. Now It is interrupting my flow to have to refresh that page.
I’ve also been experiencing this issue for the past couple of weeks, and don’t think it’s resolved yet. I’m using Chromium on Arch linux (Version 73.0.3683.86 (Official Build) Arch Linux (64-bit)).
My colleague uses Chrome on Manjaro and has been experiencing the same issue. It used to work perfectly, now it’s really annoying having to refresh the whole page to get status updates.
Hi - any word on when this might be fixed - it’s starting to get really really annoying. All our builds are now multi-step workflows. Hitting page reload every 30 seconds to see whats going on is not a great experience.
I have also been experiencing this, going on for a couple of weeks now. The issue has been occurring today, and is quite pervasive throughout the entire CircleCI web ui. Nothing seems to update automatically anymore, any changes in status (even when interacting manually, such as manually canceling a job or workflow) requires manually refreshing the site to actually see the correct status on the web page. This has effectively rendered all the various dashboards in CircleCI unusable, as the only things that seem to update are run timers…and even those will count past the completion time of a job if the site is not refreshed.
Well, I don’t mean to make the situation sound too dire.
I do, however, see a dashboard as a tool that keeps you informed, and generally “informed at a glance”. Right now, with the issue as it exists at present, the CCI dashboards are not keeping me informed. They are indeed keeping me with my finger on the refresh button every minute or two, but they are otherwise not doing their job to keep me informed at a glance, and we often have numerous builds for multiple projects in progress that we are waiting on.
I’ve been in the same boat today, spamming refresh buttons on the CCI site. I am wondering if there is a deeper issue here. Half the time when I refresh a page, I’ll get a spinner or two in various different areas of the dashboard and they will just spin and hang. Sometimes this will last for 5-10 minutes before I can get the site to actually respond again. I am not sure if this is just a byproduct of an increased number of CCI users doing the same thing I am…manually refreshing the site to get current status, so the CCI web servers are getting overloaded? Or is this indicative of a potentially deeper issue with CCI’s dashboards?
errors for POST requests to https://api.segment.io while on CircleCI and I think this has to do with this issue. Also, turning off AdBlock seemed to help (less errors in the Chrome Debug terminal and updates more often).
I noticed that some requests were being blocked, and disabled my ad blockers. Those requests stopped showing up as blocked, but disabling ad blockers did not actually seem to have any impact on the issue overall. It seemed to behave the same, with only the timer for running jobs updating, and no other status updating.
I did notice that, on rare occasions, if the page is left for quite some time, that eventually it sometimes updates. But after that it will again hang, and no longer show updates to status, no new jobs/workflows, etc.
And…the issue does appear to be ongoing still. I find myself hitting reload quite a lot on CircleCI these days just to keep track of the progress of my various workflows. It also seems that CCI servers start to see my refreshes as an attack after a while, or so I’m assuming, as after that it seems like my ability to refresh is broken until I leave things alone for about 15-20 minutes then try again.
Has there been any progress identifying what the issue here is?
Not yet. It’s still in the next up queue, but as we are working on a new UX design I think that team is waiting to see if it’s still an issue first after that is rolled out, rather than doing work that could get replaced and be not the best use of time.
I am chiming in again about this issue, “again” because I’ve posted on another topic that was also discussing this issue. First of all, I’m sorry for the exasperated/frustrated tone of my message.
I disagree with waiting to see whether the new UI solves the issue.
First, it looks like waiting for some kind of magic or miracle to happen, which is unsettling to me because it hints at the team not having an idea as to the root cause of the issue, or not willing to look for it.
Second, I’m wondering what would happen in case the new UX does not happen to solve the issue as a side bonus? It will only be more weeks and months lost waiting for a fix.
Third, this issue has been around for almost two months. I guess that the numbers should speak in favor of not letting it linger. How many users are impacted? How many builds were started in six weeks? How many customers jumped onboard to this dashboard instead of the one that was working? How high should these numbers get before the situation is deemed unacceptable?
Late March, there were supposedly only two higher priority issues. This is May and the issue is still here and my team and I are still in the same position than when the issue surfaced. And it seems from the last update that fixing the issue has been indefinitely postponed.
I understand the notion of “the best use of time” but is there nothing being lost in the meantime customer-side? Is the expected release date of the new UI known? How close is it to completion? My point here is that [I believe that] restoring such an essential feature in the current UI trumps any concern of efficient use of time.
But again, many apologies; this is just the opinion of a frustrated development team manager.
Similarly to you I don’t want to have a go at fellow laborers but if we had such an issue on our product I would feel customers had every right to be quite angry at this point. The UI does not accurately reflect build status/es - this is a significant bug.
I’d like this to get fixed regardless of some sort of UI update. Core features working should always trump UI. I think as a product that is essentially for other developers the product management team would understand this.