This changes how a number is computed. Your charts can move without your data moving. Each change is named below with the reason for it.
What was wrong
ClickUp reports one entry per status, timestamped with the last time a task entered it. We used to end each status at the next status's timestamp. That is correct for a straight path. It is wrong when the task later bounces back and forth, for example between Ready for test and In review.
Example: a task enters PR opened on day 1 and moves to Ready for test on day 21. It then goes back and forth with In review until day 35. ClickUp stamps Ready for test with day 35, its last entry. So the Bottleneck Detector showed PR opened from day 1 to day 35, two weeks longer than it really was.
What changed
Each status now ends at whichever comes first: the next status's timestamp, or the moment the task reaches the total time ClickUp recorded for that status. In the example, PR opened now runs from day 1 to day 21.
What you will see
These numbers go down wherever a status was followed by a loop, and stay the same where it was not:
- Workflow Bottleneck Detector: hours per status, and each status's share. The drop is largest in statuses that sit before a loop: backlog states such as Created, To do and Open, then In progress and PR opened. A task whose only time in a status was a visit ClickUp did not date leaves that status's task list, so the task count and the average per task can change too.
- Cycle Time: it adds up the hours a task spent in your cycle-time statuses, so it goes down for tasks that went through review or test loops.
- Parallelism Factor, because the hours of overlapping work shrink.
- Hours built from time in a status: average hours by status; total, billable and active-work hours; development, QA and review hours per task; milestone stage times.
- Cost and budget figures priced from those hours.
Ratios built from these hours, such as hours per story point and Delivery Pace, are recalculated too. Their direction depends on how much each period had been inflated, so they can move either way.
These do not change:
- Lead Time. It runs from the first entry into a start status to the close, and neither moment changes.
- The Lead Time Path total. Part of it is now shown as undated time: ClickUp counted that time but did not date it, so it is no longer credited to the wrong status.
No status can now show more time than ClickUp itself recorded for it. ClickUp does not send dates for earlier visits to a status that the task entered again later. That time is no longer credited to the wrong status, but it is not placed on the timeline either, so per-status hours can read slightly below ClickUp's own totals.
Also fixed today: a nightly refresh that did not finish
The nightly recalculation of per-task hours had not been completing since at least 13 October. Tasks that changed were still updated as they changed, but tasks nobody touched kept hours from an earlier calculation. We fixed the cause, and the recalculation completed again on 19 October. On that day Cycle Time and the other hours listed above can move by more than this change alone accounts for, because every task was brought up to date at once.
What to do
Nothing. Your numbers are recalculated from your ClickUp data. If you compared bottlenecks or cycle time against an earlier period, compare again now: both periods are recalculated the same way.