The GitHub Archive Data Cliff

Holding time of day constant at 15:00 UTC, the last hour we sampled with a full payload is 8 October 2025. Every sample from 9 October onward carries five fields. The transition is binary: there is no partial or gradual degradation between the two.

The 9 October 2025 file is unusually small, and a handful of hours in that week are partial or missing entirely. That disruption is separate from the schema change: the field count never recovers once the archive resumes normal volume on 16 October.

What Survived, and What Did Not

"You can still see that a pull request happened. You cannot see who opened it, when it merged, how big it was, or whether anyone reviewed it."

Most Research Is Not Dead. It Moved.

The obvious conclusion from the field list is that PR research on this dataset is finished. That is what we assumed too, and measuring the post-cliff files properly shows it is wrong. Most of what the removed fields supported is still derivable, because the information moved from inside the pull_request object to the event around it.

Three things survive that make the difference. Every event still carries a top-level actor with a login, so authorship is available even though pull_request.user is not. Every event still carries a top-level created_at, so actions are timestamped even though merged_at is not. And PullRequestReviewEvent was left almost untouched: it still returns a full review object with state, body and submission time.

"The data did not disappear. It stopped being handed to you in one piece."

What each metric now takes

The cost is real but specific. Reconstructable metrics need you to hold state across the timeline rather than read one row: to get cycle time you now join an opened event to a merged event for the same pull_request.id, which means processing a continuous span of the archive rather than sampling a month. That is more work, and it means late merges fall outside whatever window you process.

Pull request size is the one genuine casualty. There is no event-level substitute for additions, deletions or changed_files, which is precisely the data behind the size-versus-review-quality findings that this kind of research is best known for - including our own. Those cannot be refreshed from this source at any price.

Why This Matters Beyond One Dataset

Public GitHub data has been the default evidence base for claims about how software gets built. Benchmarks about review coverage, PR size, merge timing and contributor onboarding are routinely sourced from it, by vendors and academics alike. Those analyses did not all die on 9 October 2025, but the ones that were a single query over a month's table now either need rewriting against the event stream or cannot be done at all.

The practical consequence is a silent break in comparability. A study that reads pull_request fields will return far fewer usable rows after the cutoff rather than failing loudly, so a naive year-over-year series can keep producing numbers that are not measuring the same thing. Anyone publishing a PR-size benchmark for a period after October 2025 is drawing on a different source, and it is reasonable to ask which.

"The dangerous part is not that queries fail. It is that they still return rows."

No BigQuery account is needed. GitHub Archive publishes one gzipped JSON file per hour, one event per line, and they are public. Download any two hours either side of the boundary and compare:

# One hour from before the change, and one from after
curl -O https://data.gharchive.org/2025-10-08-15.json.gz
curl -O https://data.gharchive.org/2026-08-25-15.json.gz

# Count the fields on the first PullRequestEvent in each
python3 - <<'EOF'
import gzip, json, sys
for path in ("2025-10-08-15.json.gz", "2026-08-25-15.json.gz"):
    with gzip.open(path, "rt", errors="replace") as f:
        for line in f:
            e = json.loads(line)
            if e.get("type") != "PullRequestEvent":
                continue
            pr = e["payload"].get("pull_request") or {}
            print(path, "->", len(pr), "fields:", sorted(pr)[:8], "...")
            break
EOF

We sampled 9 hours at 15:00 UTC to hold time of day constant, plus additional hours on the boundary dates and two extra hours in August 2026 to check that a single file was not misleading us. Counts are of every line in each file, not a sub-sample.

The data still exists, it is just no longer in the firehose. GitHub's REST and GraphQL APIs return the full pull request object per repository, which is how any tool that reports on your delivery data gets it today. The trade is that you query repository by repository with authentication and rate limits, rather than reading one global stream.

So there are two routes now rather than one. Stay on the archive and rebuild the metrics from event sequences, accepting that PR size is gone and that you must process a continuous span rather than sample a month. Or select a sample of repositories and pull their full pull request history from the API, which restores every field including size but makes your result a sample rather than a census. Neither is as convenient as one query over a month's table, and the second is the only one that recovers PR size.

For measuring your own organization none of this changes anything, because per-repository API access was always the route there.