Evidence note: This article rests on a single primary source — GitHub’s own changelog announcement of the change. Vendor announcements are treated here as established fact about what the vendor said and shipped, not as independently corroborated descriptions of behaviour; no third-party report, reproduction, or measurement of this change is cited below, and none has been performed for this piece. Where the announcement stops short of specifying something, that is marked as open rather than filled in.
The change, in one sentence
GitHub announced on 25 September 2026 that queries for workflow runs in the GitHub Actions API and UI now return a less precise but more accurate count of records when searched by workflow, event, status, or branch (GitHub changelog, 25 September 2026). The announcement carries the title "Changes to query results in the GitHub Actions API and UI" and is dated 25 September 2026 (evidence level: vendor’s own changelog post, date and title as published).
That one sentence contains the whole story and also the whole oddity. A count got worse along one dimension and better along another, and the vendor chose to lead with the improvement.
The four filters it touches
The scope GitHub states is narrow and specific: the new counting behaviour applies when workflow runs are searched by workflow, event, status, or branch (evidence level: vendor’s own changelog post). Those four are the filters that most dashboards, triage scripts, and flake-hunting queries actually use — "all failed runs on main", "every run triggered by pull_request", "runs of the nightly workflow this month."
What the announcement as published does not spell out is the mechanism: whether the count becomes an estimate above some threshold, whether it is capped, whether it is derived from a sampled or approximate index, or whether the imprecision scales with repository size. Those details are open. Anyone depending on the exact figure should treat the shape of the new number as undetermined until it is tested, not inferred from the word "less precise."
Both surfaces at once
The change applies to both the GitHub Actions API and the GitHub Actions UI (evidence level: vendor’s own changelog post). This matters more than it first appears, because it removes the usual cross-check. When an API changes and a web view does not, a developer can compare the two and see which one moved. Here both surfaces shifted together, so the number in a browser tab and the number in a JSON response are expected to agree with each other — and to disagree with what either would have reported before 25 September 2026.
The practical consequence: a screenshot of a run list is no longer independent confirmation of an API total. They are now two windows onto the same recalculated figure.
Reading the changelog’s own description
The phrasing is worth dwelling on because it is doing unusual work. Vendors rarely announce a loss of precision at all, and almost never in the same clause as a claimed gain. GitHub’s construction — less precise, more accurate — reads as a deliberate trade rather than a regression being softened.
The most defensible reading is that the previous count was specific and sometimes wrong, and the new one is vaguer and more often right. That is an interpretation of the vendor’s wording, not a separate claim the vendor made, and the announcement as published does not elaborate on what was inaccurate before. The reason for the trade is therefore open.
Precision and accuracy are not the same property
The two words are not synonyms, and the distinction is the entire point of the announcement.
Precision is how finely a number is reported and how consistently it repeats. 1,428 is precise. about 1,400 is not.
Accuracy is how close the number is to the truth. 1,428 is imprecise about nothing and can still be wrong by three hundred.
A count can be precise and inaccurate — the classic failure mode of a query that reports a confident total derived from a partial or stale index. It can also be imprecise and accurate, which is what a bounded or rounded figure buys: less resolution, fewer outright lies. GitHub’s stated direction of travel is from the first state toward the second.
This is a familiar trade outside software. A scale that reads 71.384 kg when a person weighs 74 kg is precise and useless. One that reads between 73 and 75 kg is neither impressive nor wrong.
What the change does not touch
Nothing in the announcement concerns the run records themselves. A workflow run that happened still happened; its logs, its conclusion, its timestamps, and its artifacts are unaffected by how a query totals them up. What changed is the cardinality reported for a filtered search, not the underlying data being searched.
That boundary is the reason this is a reporting change rather than a data-loss event. Enumeration — paging through the actual results — remains the path to a record-by-record answer. The count is a summary; the summary got a different contract.
Developer takeaway: a filtered total is now a reading, not a ledger
The operational implication is concrete. Any automation that treats a filtered workflow-run count as an exact ledger entry should be reviewed:
- Assertions on exact counts. A check that fails when
total_countis not exactly the expected integer is now testing a figure the vendor has declined to guarantee at that resolution. Prefer thresholds and ranges. - Diffing counts across time. Comparing today’s filtered total against one recorded before 25 September 2026 compares two different calculations. Treat the boundary date as a discontinuity in any stored time series.
- Billing, SLA, or compliance figures. Where a number must be defensible, derive it by enumerating runs and counting them locally, not by reading a filtered total.
- Dashboards. Rounding the display to match the guarantee is more honest than showing four significant figures the API no longer promises.
- Pagination logic. Any loop that computes page count from the reported total, rather than following the returned links until they run out, is the most likely place this bites silently.
The general rule this change makes explicit: a count returned by a filtered query is a reading from an instrument, with an instrument’s tolerances. It was arguably always that. Now it is labelled.
Readers tracking how this story developed may also want the earlier coverage of GitHub Actions run queries returning a less precise count. For a case where a GitHub changelog’s own dating was the notable detail, see the account of Copilot’s expansion into Slack and Teams and the roundup dated four days earlier than the change.
The follow-up that has not been run
The obvious experiment has not been performed, and nothing above should be read as if it had. It is stated here as a proposal, with its method, so the gap is visible.
The question: by how much, and in which direction, does a filtered workflow-run count diverge from an enumerated one?
The method: pick a repository with a substantial run history. For each of the four named filters — workflow, event, status, branch — issue a filtered query and record the reported total. Then page through the full result set for the same filter and count the records returned. Record both numbers, the repository’s approximate total run volume, the date, and the API version used. Repeat across repositories of different sizes, because the most useful unknown is whether the gap is a constant, a percentage, or a cap.
What it would establish: whether the imprecision is bounded and predictable enough to build on, and whether the divergence grows with scale. Until that is measured, the size of the gap is open. What is known is only what GitHub stated: the count changed character on 25 September 2026, on both surfaces, for those four filters.