Missing GitHub Statistics Are Not Zero Activity

A blank GitHub statistics response does not tell you that a repository stopped working. It can mean the calculation is pending, the endpoint returned no content, access failed, or your collection did not finish. Collapsing those states into zero creates false drops and misleading rankings.

This guide is about handling missing public-code measurements. It does not diagnose a company's health from an API response. Use the site's methodology to understand the activity metric, then preserve uncertainty when the source cannot supply it.

Read the status before the number#

GitHub's repository statistics documentation says statistics can be returned from a cache. If the calculation is not cached, the request can return `202` while a background job compiles the statistics. A later request can return `200` when the calculation has completed.

A `202` is therefore a pending measurement, not a measured zero. Store it as pending and leave the activity value unset. Record when you checked so another analyst can distinguish an old failure from a current one.

The commit-activity endpoint also documents `204` as a no-content response. Do not invent a numerical meaning for that response. Your table should preserve its status rather than converting the missing body into an array of zeroes.

Know which limitation belongs to which endpoint#

Statistics endpoints are not interchangeable. GitHub documents a 10,000-commit limitation for the code-frequency endpoint, which returns additions and deletions. The contributor endpoint also has a documented limitation affecting addition and deletion values in large repositories.

Do not transfer a limitation from one endpoint to every GitHub metric. Keep the exact endpoint and its documented response behavior in the collection log. If the statistic is unsuitable for the repository, mark that measurement unavailable and choose another explicitly defined observation rather than filling the gap with a guess.

GitHub statistics also exclude merge commits. Contributor statistics exclude empty commits. A valid low value may therefore differ from a count taken from another source. That is a definition mismatch to investigate, not necessarily a missing-data problem.

Give each result a state#

A practical table keeps the value and state separate:

**Observed:** a valid response was parsed and the measurement is available.

**Pending:** the provider accepted the calculation but has not returned it.

**No content:** the endpoint returned no usable measurement.

**Access unresolved:** authentication or permission needs checking.

**Rate limited:** collection stopped to honor the provider's limits.

**Incomplete:** a page or repository in the intended collection is missing.

These are suggested labels for your own workflow. They are not statuses claimed for the site's pipeline. Add the response code, collection time and explanatory note next to each label.

A real zero belongs only in the observed state when the valid response and counting rules support it. That distinction should survive export to CSV, a dashboard and any later API consumer.

Retry without turning collection into a storm#

GitHub's API best-practices guide recommends avoiding unnecessary polling and making requests serially to reduce secondary-rate-limit risk. Honor `retry-after` when present. When the remaining allowance is zero, respect the reset header rather than immediately trying again.

For a secondary rate limit without those instructions, the guide describes waiting before retrying, increasing the wait after further failures and stopping after a bounded number of attempts. It also warns that continuing requests while rate limited can result in a ban. A data gap is preferable to damaging access.

Define a retry ceiling before collection starts. When you hit it, preserve the gap and report its consequence. Do not keep retrying because the chart would look cleaner with one more number.

Do not hide incomplete coverage#

If you intended to measure several repositories and one is missing, disclose both the completed coverage and the missing part. Do not compare a complete earlier period with an incomplete later period as though both cover the same population.

For paginated lists, the pagination guide explains the next-page links in the response header. Finishing only the first page can undercount records even when the request succeeded.

Use the trending view as a starting list, then inspect the measurement behind a candidate. The blog can explain the workflow, but neither surface fills a failed source response. A watchlist entry should say whether its comparison is complete, approximate or currently unavailable.