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.
Some of your charts changed without your data changing. That is our doing. This page names each change, when it landed, and how large the effect can be, so that a figure you have already reported to your board is explainable rather than mysterious.
Read this part first: what is still wrong today
Some of this work is unfinished. If you are about to rely on a number from one of these screens, check it with us first:
- Cost Analysis — project and task cost, and the story-point roll-ups beneath them. It also does not yet apply your selected View's lens.
- The accounting exports (CSV, XLSX and PDF).
- Time Tracking's calculated hours, and its status-bottleneck drill-down.
- Velocity's Tasks Completed drill-down, where a descendant story-point roll-up compounds with the depth of the tree — this is the one to check before trusting a rolled-up total for a large hierarchy.
- The milestone completion-trend chart, which can count one task in two periods.
- The over-baseline "problem tasks" list — this one is not inflated but non-deterministic: it collapses on an arbitrary revision, so the same query can return different rows on different runs.
- Anything that picks a revision by close date rather than by sync order. Two revisions of one task usually share a close date, so the tie is broken arbitrarily and the figure can change between runs without your data changing. This affects the Velocity category distribution and its task drill-down, the sprint summary, tag inheritance, the QA allocation trend, and — not otherwise obvious from the list above — milestone burn-up, milestone KPIs, per-person velocity, rework and decomposition quality. We are not putting a count on it: our first attempt at one did not reproduce, and the surfaces are more useful to you than the number.
- Per-person DORA filtering, which resolves people by display name, so two people sharing a name are merged into one.
- Milestone stage hours, reopen and blocked rates.
- The status bottleneck list, where duplicate rows consume the hundred-row limit and can push genuinely slow tasks off the end.
- Tag trends, which can count one task in two periods.
- The task detail view, which divides hours by everyone ever assigned rather than by who is assigned now.
If you are relying on any of these in a budget or a board pack right now, contact support and we will reconstruct the figure for you. Everything below explains what changed and by how much.
What changed, item by item
1. Cost Analysis attributed whole tasks to whoever you filtered by
Changed 17 August 2026.
Filtering Cost Analysis by a person or a team credited them with the entire hours of every task they had touched, rather than their share of it. Stage hours and every cost derived from them were inflated for any filtered view.
How large is this? Measured on one engineer over one month: their stage breakdown read 4,761 hours against the 1,815 actually attributable to them — 2.6 times too high. We have not measured it across a whole company. Your figure depends on how much of your work is shared; the more collaborative the task, the larger the overstatement was. Unfiltered, company-wide cost totals were not affected — the share factor is only applied when you filter.
2. Report metrics now identify people by tracker id, not by display name
Changed 17 August 2026.
The reports metric catalog matched people by name. Names are neither unique nor stable: in our own workspace 35 names hold two tracker accounts each. Those metrics now key on the tracker's own user id.
How large is this? Attributed story points, per-person cost and the work-concentration (Gini) distribution can all move for anyone who was merged or re-seated in your tracker. People with a single account are unaffected.
Not yet covered by this change: the story-point rate basis queries by seat correctly, but collapses those per-seat rows by display name when assembling the result, so a second seat overwrites the first and its story points are lost rather than split. And the seat-to-person mapping underneath is still bootstrapped by grouping on display name — which is why per-person DORA filtering still merges namesakes.
3. Duplicate task revisions no longer inflate counts
Corrected 19 August 2026, and not finished.
We store each task as a series of revisions. Several places that read them counted every revision instead of only the most recent, so a task edited several times could count several times.
How large is this? Measured on our own data on 1 September:
- Row counts on non-milestone tasks run about 4% high (93,335 rows against 89,505 tasks).
- Summed story points run about 9.5% high (32,868 against 30,009). Note this one counts all tasks including milestones, where the row figure above excludes them — milestones carry far more revisions, so the two are not directly comparable.
- Most tasks are unaffected. 99.4% carry exactly one revision. The damage is concentrated in the 557 that do not — one task holds more than 180 revisions — so a total dominated by heavily-edited work is wrong by far more than these averages, and a total of write-once tasks is not wrong at all.
- The bottleneck list silently loses rows. Duplicates consume the hundred-row limit, so genuinely slow tasks can be pushed off the end rather than shown wrongly.
We have not measured the per-screen effect on the accounting exports, Time Tracking, or descendant story-point roll-ups, so we are not going to publish a number for them. Treat any figure from those screens as potentially high by more than the averages above until we have. The queries behind everything we do state are published here, with the date each was run.
Still wrong today. Currently uncorrected: Cost Analysis (project and task cost, and the story-point roll-ups beneath them), Milestone stage hours, reopen and blocked rates, Time Tracking's calculated hours, the accounting exports (CSV, XLSX and PDF), and the status bottleneck list.
Two related defects found in the same review, and also not yet fixed: tag trends can count a task in two periods when it was synced both before and after closing, and the task detail view divides a task's hours by everyone ever assigned to it rather than by who is assigned now, which under-attributes per-person hours and cost on reassigned tasks.
Each is being corrected with its own verification against fixed test data.
If you are relying on a Cost Analysis or accounting-export figure in a budget or a board pack right now, contact us and we will reconstruct it for you.
4. Velocity, Time Tracking and Reports measure through your selected View
Changed 27 August 2026.
A View carries the lens a metric is computed under — which of your tracker statuses count as active work, and where cycle time and lead time start and stop. Several surfaces applied your team and people filters correctly but ignored that lens, falling back to the company defaults: Velocity's completed-task feed, Time Tracking's task table, lead time, cycle time, and the sprint summary. All of those now compute through your selected View's lens.
How large is this? Nothing changes if your View uses the company's default time boundaries — most do. The part that moves totals is the lead-time boundary: a View that defines its own excludes tasks that fall outside it, so the set of work behind a lead-time figure can change. A custom status mapping changes how time is attributed across stages, not which tasks are counted. Who was included did not change.
Be aware of the gap this leaves. Cost Analysis does not yet apply the selected View's lens. It does apply your team and people selection, but computes under the company defaults, so a story-point figure on Velocity and a cost figure on Cost Analysis may not describe work the same way. Time Tracking's status-bottleneck drill-down has the same gap. We are closing both, and it will appear here when it lands.
5. Milestone cycle time filtered by assignee returned an error, not a number
Broken and fixed on 19 August 2026, by us.
This one was our own doing, and it is worth being precise about what we do and do not know.
The revision-collapse work in item 3 moved a query's filter into a position the database could not parse, so milestone cycle time returned an error rather than a number. It was committed at 08:12 UTC on 19 August and fixed at 23:32 the same day — about fifteen hours between the two commits. We cannot confirm the broken code was ever deployed to customers: there is no release between those points that we can evidence, and it was caught by review rather than by anyone reporting it.
Had it shipped, the effect would have been wider than "filtered by assignee": anyone who is not an Admin has an access filter applied automatically, so every Manager, User and Viewer would have hit it on an ordinary unfiltered page view.
We are listing it because a fifteen-hour self-inflicted break belongs on this page whether or not it escaped, and because saying "we think it did not reach you, and here is why we cannot be certain" is more useful than silence.
6. The health score explained itself with an impossible number
Committed 19 August, fixed 28 August 2026.
The panel that explains why your organisation health score moved validated only the previous period's value before multiplying. A non-finite current metric or weight produced an infinite contribution, and the panel presented that as the reason the score changed.
How large is this? The score itself was not affected — only the explanation beside it. If you read a health-score driver in that window and it looked nonsensical, that is why. As with item 5, we cannot say precisely when it reached production — our deployment records do not go back far enough to tell us.
Corrections to this page
This page is itself subject to the standard it sets, so its own changes are recorded here rather than made quietly.
1 September 2026. An earlier version of this page stated that an August window inflates the accounting export "by about 16%" and Time Tracking's hours "by about 14%", and that "about 99% of hierarchies are unaffected" by the descendant roll-up defect. Those figures were published without measurement. When we measured, the first re-derived at 2.7% — roughly six times smaller than what we had printed — and the second had never been measured at all. All three were withdrawn. We now publish only figures whose query and date are recorded alongside this note, and we say plainly where we have not measured. That version was live from 22:34 to 23:31 UTC — about an hour.
2 September 2026 (morning). An earlier version listed DORA per-person filtering as still matching people by display name. We removed it, saying it had been fixed on 17 August in the same change as the rest.
2 September 2026 (later). That removal was itself wrong, and we have put the item back. DORA per-person filtering does still resolve people by display name, so namesakes are merged; what changed on 17 August was how ClickUp names are bridged to GitLab usernames, in a separate commit from the reports work. We also published "27 names had both accounts assigned to the same tasks" in item 2 and have withdrawn it — we could not reproduce that figure when we went back to check, and the two-seat count is 35, not 34.
Three corrections to one page in two days is not a good look, and publishing them is the point: the alternative is a page whose errors are invisible.
If a number you reported has moved
Contact support with the specific figure, the date range, and the View you were using, and we will reconstruct what that number was before and after the change, for your data.
Every date on this page is the date the change was committed. Four of these six reached production from a release branch rather than through our trunk, so "merged" would be wrong. Where we can also evidence when a change reached production we say so; where we cannot, we say that too.
This list covers the changes we identified. It is not a guarantee that nothing else moved — if you find a figure this page does not explain, tell us, and we will investigate it and add it here.