A business dashboard can look healthy even when one of its numbers has stopped meaning what everybody thinks it means. The connection still runs, the report still arrives and there may be no obvious error. A quiet change in an external system can turn an exact total into a threshold, omit older records or alter which items appear. If the receiving system treats the result as unchanged, a technically successful integration produces a misleading business answer.
GitHub has provided a small but useful example. In a 25 September announcement, it said searches for workflow runs in the GitHub Actions API and user interface will stop reporting an exact total when more than 2,500 records match. The result will show 2,500+. GitHub will still return paginated results of up to 1,000 items, and integrations that need more than 2,500 matching runs are being told to narrow their filters, for example by adding a date range.
GitHub made the change because large queries frequently timed out and returned the number found before the timeout rather than the true total. The old exact-looking figure could therefore be wrong. The new threshold is less precise, but it is more honest.
That distinction matters well beyond software delivery. Many businesses depend on APIs to feed management reports, customer portals, finance reconciliations and operational alerts. Those systems need to understand what a value represents, not simply whether a field contains a number.
What Has Actually Changed
A GitHub Actions workflow is an automated process commonly used to test, build or release software. Each time it runs, GitHub stores a record with information such as the workflow, branch, status and person or event that triggered it. Teams and reporting tools can search those records through the API.
Previously, a broad query might appear to provide an exact count even when retrieving the full result took too long. A total of 2,183 could look authoritative while really meaning that 2,183 records were found before the request stopped. GitHub's revised behaviour makes the uncertainty explicit. Once matches pass 2,500, the reported count is 2,500+ rather than a precise total.
There are two separate limits to understand. The count becomes a threshold above 2,500, while a query still returns no more than 1,000 paginated items. An integration cannot safely read the headline count, fetch one page and assume it has the complete population. If it needs an exact result, it must divide the request into narrower, non-overlapping slices and combine them deliberately.
The announcement is only a minute's read, but it exposes a common weakness in connected systems. Data contracts include meaning, completeness and limits as well as field names. Code can continue parsing the response after one of those conditions changes.
A Release Report From Start to Finish
Consider a business with several customer-facing web applications. Its delivery manager receives a monthly report showing how many automated build and deployment runs completed, failed or were cancelled. The figures are used to spot unreliable releases, estimate support effort and reassure customers that agreed maintenance work is happening.
An overnight integration asks GitHub for all workflow runs, follows the pages returned, classifies each status and writes a monthly summary into the company's reporting database. A dashboard then shows failure rate by application and compares the latest month with the previous six. When a failure rate rises, the delivery manager opens the underlying run and assigns an investigation.
As usage grows, a broad query crosses 2,500 matching records. If the integration converts 2,500+ to 2,500, or ignores the plus sign, the denominator is understated. If it fetches only the first 1,000 records, the problem is worse: the dashboard may still calculate a neat percentage from an incomplete and potentially biased sample. Recent runs could dominate one page while older failures sit elsewhere.
The dependable route is to query one defined reporting period at a time, using explicit start and end boundaries. The integration follows every page within that period, stores the source run identifier so retries cannot create duplicates and records the extraction time and filter used. It then checks that statuses add up to the number of records actually collected. If the source returns a capped count, repeats a page or cannot complete the period, the report is marked incomplete and the delivery manager sees an exception instead of a polished percentage.
At the end of the process, the business has more than a chart. It has a traceable set of source records, an exact reporting window, a visible completeness check and a route for resolving failures. When somebody asks why June's deployment figure changed after a correction, the team can reproduce the query and explain the answer.
How Quiet Data Errors Reach the Business
The most dangerous response to an API change is often a successful one. A broken authentication token generates an error and attracts attention. A changed definition can pass every technical health check because the request returns on time and the response is valid.
Type handling is one risk. Software expecting an integer may reject 2,500+, quietly substitute zero or strip the non-numeric character and store 2,500. Each behaviour has a different consequence, yet all can begin with the same apparently minor source change.
Pagination is another. APIs often return a sample or page alongside a total. The total describes the match set, while the current response contains only part of it. If a developer tests with a small account, both values may happen to agree. The mistake becomes visible only after the business has accumulated enough data, usually when the report has become important.
Time boundaries can also create gaps and duplicates. Splitting a large request by date works only if the system defines whether each boundary is inclusive, uses one timezone and copes with records arriving late or being updated afterwards. A sensible design overlaps extraction windows slightly and deduplicates by a stable source identifier. It can then pick up late changes without counting the same event twice.
Historical reports need care as well. If a dashboard recalculates old months directly from a live source, retention policies and source corrections may make last year's number drift. Sometimes that is desirable, but it must be deliberate. For formal operational reporting, storing the underlying records and the calculation version usually gives a clearer audit trail.
Treat Integrations as Maintained Business Systems
An integration is not finished when two systems exchange data for the first time. The supplier will change limits, definitions, authentication rules and retention behaviour. The receiving business will change how it uses the result. Somebody needs to own the contract between them.
That owner does not need to read every vendor changelog. The system should make significant assumptions testable. Automated checks can use known small datasets, verify page traversal, reject capped totals where an exact figure is required and alert when the response shape or completeness rule changes. Management reports should display when they were refreshed and whether the source extract completed successfully.
The business also needs to decide how much precision the decision requires. A screen showing that activity exceeds 2,500 may be perfectly adequate for capacity monitoring. A customer invoice, compliance return or service-level calculation needs an exact, reproducible population. Building an elaborate extraction process for every approximate trend wastes effort, while using an estimate for a consequential decision creates avoidable risk.
GitHub's change is a responsible correction to an exact-looking number that was not dependable at scale. It is also a reminder that clean dashboards inherit every assumption made by the systems behind them. Reliable reporting comes from preserving meaning all the way from the source query to the decision, including the awkward moments when the source can only say there is more data than it can count in one go.
Birdcage Tech builds bespoke integrations, reporting tools and automations that carry business information from source to decision with clear checks, exception handling and ownership. If a spreadsheet or dashboard has become critical but nobody can confidently explain where its figures came from, we can help map the flow and make it dependable.
