34 critical GitHub outages since April. 98% of Rust still lives there

Short answer: Rust depends on GitHub almost completely. I pulled the repository link of the 10,000 most-downloaded crates on crates.io on Oct 24, 2026: 95.7% point at github.com, the top 100 is 100% GitHub, and those crates carry 98.1% of all downloads. Over the same stretch GitHub's own status page logged 34 critical incidents since April 2026, after zero from Nov 2024 to Mar 2026. Your cargo build survives a GitHub outage. Logging in to crates.io, reading the source, filing a bug and Trusted Publishing do not.

TL;DR: Roku moved its developer repos from GitHub to GitLab today and Hacker News instantly guessed why: the outages. So I measured how exposed Rust is. Of the top 1,000 crates, 979 live on GitHub and only 21 do not. Brand-new crates are not leaving either: of the 2,999 crates published Oct 21 to 24, 90.0% point at GitHub and just 18 (0.6%) at Codeberg or GitLab.com. Meanwhile GitHub's major-or-critical incidents went from 3.2 a month to 8.4 a month. Our own game builds from 737 crates and 710 of them live on GitHub. Every row is in the CSV.

Key numbers

What	Number	Source, checked Oct 24 2026
Top 100 crates (all-time downloads) with a github.com repo	100 of 100	Our crates.io API pull
Top 1,000 crates on GitHub	97.9% (979)	Our pull
Top 10,000 crates on GitHub	95.7% (9,565)	Our pull
Share of the top 10,000's downloads that are GitHub-hosted crates	98.1% of 502.6 billion	Our pull
Newest 2,999 crates (Oct 21 to 24) on GitHub	90.0% (Codeberg + GitLab.com: 0.6%)	Our pull
GitHub incidents rated "critical", Apr to Oct 24 2026	34 (0 from Nov 2024 to Mar 2026)	githubstatus.com history
Major + critical incidents per month	3.2 before April, 8.4 since	githubstatus.com history
Ways to log in to crates.io	1 (GitHub)	crates.io team, Jul 13 2026
Our game LAWN WAR: dependencies hosted on GitHub	710 of 737 (96.3%)	Our Cargo.lock

Download the data (CSV, 14,999 rows: every crate in the three lists with its rank, repository URL, host, forge, downloads and created date) and GitHub's incidents by month (CSV, 24 months by severity).

Roku left. Hacker News already knew why

This morning Roku announced that its developer repositories now live on GitLab instead of GitHub. It hit the Hacker News front page within the hour. Roku gave no reason, and the thread filled one in anyway. The reply that sums it up: "like having a dozen outages in the last couple months isn't a good enough reason why?"

That guess is not crazy. GitHub's own status page shows 18 incidents in the first 24 days of October, six of them rated critical. On Oct 7 alone there were two critical incidents with Git Operations, Issues, Actions and Pull Requests. And Roku is not first. Zig moved to Codeberg in November 2025, with Andrew Kelley writing that GitHub's "priorities and the engineering culture have rotted". In April, Mitchell Hashimoto said Ghostty is leaving: "This is no longer a place for serious work if it just blocks you out for hours per day, every day."

So here is the question nobody in the Rust world wants to put a number on: if GitHub goes dark, or decides you are gone, how much of Rust goes with it? Yesterday's piece measured Europe's kill switch in DNS. This one measures Rust's in Cargo.toml.

How I checked: 14,999 crates, one field

Every crate on crates.io can list a repository URL in its Cargo.toml. That field is where the source, the issues, the pull requests and usually the CI live. I pulled it from the crates.io API at one request per second with a descriptive User-Agent, for three lists:

• Top 10,000 by all-time downloads (the crates everything is built on).
• Top 2,000 by recent downloads (the last 90 days, so old giants don't skew it).
• The 2,999 newest crates, published Oct 21 to 24 2026 (where new code is choosing to live right now).

Then I sorted each URL by host: github.com, gitlab.com, self-hosted GitLab (Tor Project, freedesktop, Redox OS, GNOME), Codeberg, SourceHut, Bitbucket, other self-hosted servers, or no repository at all. For the outage side I pulled GitHub's full incident history from its status page (24 months, every incident with the severity GitHub itself gave it). The scripts take about four minutes end to end.

98%: Rust lives at one address

The top 100 crates are 100% GitHub. serde, tokio, syn, rand, regex, every one. The top 1,000 is 97.9%. The top 10,000 is 95.7%, and when you weight by downloads it climbs to 98.1% of 502.6 billion downloads, because the crates that left are small. The recent-downloads list says the same thing: 97.3% of the 2,000 hottest crates, 98.5% of their downloads.

Who are the landlords inside GitHub? In the top 1,000 the biggest owners are RustCrypto (57 crates), rust-lang itself (40), David Tolnay (31), tokio-rs (28) and, fun detail, Microsoft's own GitHub org with 22. The company that owns the platform also owns a slice of the crates on it.

Here is everyone in the top 10,000 who is not on GitHub. It is 435 crates, and 169 of those list no repository at all, which is not an escape plan, just a missing field.

And here are all 21 crates in the top 1,000 that live somewhere else. If you want a list of maintainers who already did the thing everyone on Hacker News says they will do "someday", this is it:

Rank	Crate	Where it lives
137	redox_syscall	gitlab.redox-os.org
157	spin	Codeberg
348	dirs	Codeberg
364	dunce	GitLab.com
371, 373	proc-macro-error (+ -attr)	GitLab.com
374	constant_time_eq	Codeberg
375	openssl-macros	no repository listed
446	oorandom	SourceHut (hg.sr.ht)
482	tiny-keccak	no repository listed
504, 524, 676	redox_users, libredox, seahash	gitlab.redox-os.org
592	protobuf	no repository listed
751	gethostname	Codeberg
931, 935	scc, sdd	Codeberg
967, 997	secp256k1 (+ -sys)	git.rust-bitcoin.org
976	enum_dispatch	GitLab.com
994	version-compare	GitLab.com

Three of those (openssl-macros, tiny-keccak, protobuf) list no repository on crates.io, so they may well be on GitHub anyway. Strictly, the top 1,000 has 18 crates that point somewhere else on purpose.

GitHub's own status page tells on it

I didn't count outages from Downdetector or angry posts. This is GitHub grading itself, month by month, since Nov 2024:

From Nov 2024 to Mar 2026 GitHub posted 308 incidents and rated none of them critical; 55 were major, about 3.2 a month. From April 2026 to today it posted 157, and 34 were critical plus 25 major: about 8.4 serious incidents a month, more than 2.5 times the old rate. The worst single month for raw count was February 2026 (37 incidents), which lines up with IncidentHub's tracker (257 incidents May 2025 to April 2026, February the worst).

Fair caveat: the "critical" label shows up for the first time in April, so part of that jump is GitHub labelling harder. Fine. Then look at major plus critical together, which is the honest comparison, and it still more than doubled.

GitHub has said this out loud. After the 7 hour 47 minute outage on Aug 17, CTO Vlad Fedorov wrote that traffic hit a new peak and "a critical infrastructure component in our Central US data center failed to scale with it", that a Copilot "client-side retry loop" made recovery worse, and that "Azure serves roughly 58% of GitHub's platform load", up from 12% in May. Translation: GitHub is moving house onto Azure while Copilot traffic stampedes through the hallway.

And the AI part is not a footnote. Of GitHub's last 50 incidents (Aug 12 to Oct 23), 13 were Copilot or AI-model incidents ("Grok 4.6 and Grok 4.7 Service Issues", "Elevated errors on Fable 5 due to upstream provider", "Degradation with Gemini 3.8 Flash"), 19 hit Actions, and 5 hit Git Operations. My read, and it is a read: Microsoft runs GitHub as the storefront for Copilot now, and the boring parts Rust actually needs (git, issues, CI) get whatever reliability is left over. They will never say that out loud. The incident list says it for them.

What actually breaks for a Rust dev when GitHub is down

Good news first, because it is real: GitHub going down does not stop your build. Since Rust 1.70 Cargo uses the sparse index at index.crates.io by default and downloads crates from static.crates.io, so cargo build never touches github.com unless you added a git = dependency. I checked four of our own workspaces (823, 527, 326 and 200 packages): zero git dependencies, zero GitHub calls at build time.

Now the bad news. Everything around the build runs through one company:

• You can only log in to crates.io with GitHub. The crates.io team said it plainly in July: "signing in means 'Log in with GitHub', and your crates.io identity is your GitHub username." Native usernames are being built "as a prerequisite for eventually supporting login via other identity providers", with RFCs still to come (Tobias Bieniek for the crates.io team).
• Trusted Publishing works with GitHub Actions or GitLab.com only. GitLab support landed in January; "self-hosted GitLab instances are not supported yet" (crates.io update, Jan 21 2026).
• The source, the issues and the security reports for 95.7% of the top 10,000 sit on github.com. When it is down, so is every "where is this bug tracked?" link in your dependency tree.

Our receipt: we got switched off, twice

This isn't hypothetical for us. On Sep 28 our GitHub account went 404: profile, every repo, GitHub Pages, the API. GitHub's security log showed a staff suspension, an unsuspension a minute later, and a randomized password. It came back on Sep 30, and about an hour later it was suspended again. It was usable again on Oct 3. We never got a reason.

The fallout was not the code. It was everything that pointed at GitHub. The privacy-policy links for our iPhone apps lived on GitHub Pages, so they 404'd, and Apple rejected an app update under guideline 5.1.1 because the "privacy policy link not functional". We moved those pages to our own host and pointed our crates' repository links at GitLab: 64 of our 70 crates now say gitlab.com.

And still. Our game LAWN WAR builds from 737 crates.io packages. I looked every one up:

710 of 737 live on GitHub (96.3%). We left, and our dependency tree didn't. That is the whole story of Rust and GitHub in one chart: you can move your own repos in an afternoon. You cannot move Bevy, serde and tokio.

Everyone says they will leave. The data says nobody is

If developers were really fleeing, it would show up first in new crates, because a new crate has no stars, no issues and no history to lose. It doesn't. Of the 2,999 crates published from Oct 21 to Oct 24, 2,698 (90.0%) point at GitHub, 215 (7.2%) list no repository, and Codeberg plus GitLab.com together got 18 (0.6%). Among the top 10,000, GitLab.com has 90 crates and Codeberg 56. The exits are loud on Hacker News and close to invisible on crates.io.

Why? My bet is gravity, not love. Your users have GitHub accounts, so issues and PRs come in there. crates.io makes you have a GitHub account anyway, so the cheapest move is the default. And GitHub Actions is free CI that every Rust template already wires up. Leaving costs a maintainer real hours; staying costs them an outage now and then, which is somebody else's fault. Until crates.io accepts another login, the Rust ecosystem is not choosing GitHub. It is enrolled in it.

Check your own project in 60 seconds

From your project folder (needs jq):

# 1. Any git dependencies? These DO break when GitHub is down.
grep -c 'source = "git+' Cargo.lock

# 2. Where does the source of every dependency live?
cargo metadata --format-version 1 | jq -r '.packages[].repository // "none"' \
  | sed -E 's#^(git\+)?https?://(www\.)?##; s#/.*##' | sort | uniq -c | sort -rn

# 3. Is your CI or release pipeline GitHub-only?
ls .github/workflows 2>/dev/null

If line 1 prints anything above 0, pin those to a published version or vendor them (cargo vendor). If line 3 lists your release job, keep a crates.io API token somewhere safe as a fallback: cargo publish with a token talks to crates.io, not GitHub. For deciding whether a dependency is worth the risk at all, our Cargo.toml checker audits advisories, licenses and MSRV in the browser, and the live GitHub API status and crates.io status pages tell you which one is actually down.

Caveats

• The repository field is self-reported. Some GitHub links are read-only mirrors (Ghostty plans to keep one), and some crates without a link live on GitHub anyway. It measures where crates point people, which is what breaks when the host does.
• I sampled three lists (14,999 rows, 12,999 distinct crates), not all of crates.io. The lists are where nearly all downloads are.
• Severity labels are GitHub's own, and "critical" only exists from April 2026. I compare major + critical to stay fair.
• Roku gave no reason for its move. The outage explanation is Hacker News's guess, and mine; it is not Roku's.
• Our account story is ours: one account, no reason given, so it proves the risk exists, not how often it happens.

Numbers so far, and my bet

Measure	Oct 24 2026	Rerun
Top 1,000 crates on GitHub	97.9%	Oct 24 2027 (bet: still above 95%)
Newest crates on Codeberg + GitLab.com	0.6%	Oct 24 2027 (bet: below 2%)
GitHub major + critical incidents per month	8.4	monthly
Ways to log in to crates.io	1	Oct 24 2027 (bet: still 1)

My bet: a year from now Rust is still 95%+ GitHub, and the first thing that changes it is not an outage. It is crates.io shipping a second login. So, the question: would you move your crate off GitHub if crates.io stopped requiring it, or is GitHub just where your users are and that's that?

More on the same beat: what the crates.io download count really measures (the study This Week in Rust featured), Europe's US kill switch, measured, and every Rust data piece on the Rust hub.

Broken build? Fixed in 24 hours

If a git dependency, a dead GitHub link or a CI move just broke your Rust build, send it to us. Fix my Rust build, $99: one build, dependency or advisory-upgrade problem, back to you as a patch or pull request within 24 hours of having the error and the repo. If we can't fix it in 24 hours, you get the full $99 back without asking. As featured in This Week in Rust.

Follow for one checked, data-backed answer to the fights Rust developers are having, every day.

Sources

• Roku, developer repositories moved from GitHub to GitLab, via Hacker News, Oct 24 2026
• GitHub, status page incident history, pulled Oct 24 2026 ~1 PM ET
• Vlad Fedorov (GitHub CTO), The August 17 outage, and the work ahead, Aug 20 2026
• IncidentHub, GitHub reliability: outage history 2025-2026
• Tobias Bieniek for the crates.io team, crates.io development update, Jul 13 2026, and Jan 21 2026
• The Rust Release Team, Announcing Rust 1.70.0 (sparse index by default), Jun 1 2023
• Andrew Kelley, Migrating from GitHub to Codeberg, Nov 26 2025
• Mitchell Hashimoto, Ghostty is leaving GitHub, Apr 28 2026
• crates.io API (repository field), pulled Oct 24 2026 at 1 request per second
• Our datasets: data.csv (14,999 rows) and github-status.csv; rerun Oct 24 2027