crates.io status

How we check crates.io

We watch crates.io from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the registry host that cargo resolves against, which is the step that decides whether a build can start at all. Crate files are served separately through a content network, so watching downloads alone would miss an index failure, which is the one that stops a build before anything is downloaded.

What is crates.io?

crates.io is the package registry for Rust, and cargo, the language's build tool, treats it as the default source for every dependency. A typical Rust project of moderate size resolves a few hundred crates through it, most of them transitively, and a build that starts from a cold cache fetches all of them before compiling a line of your own code.

The nature of the dependency is different from most registries in one useful way. Rust compiles to a self-contained binary, so once your application is built it has no runtime relationship with crates.io at all. There is no equivalent of a dependency being loaded at startup and no way for a registry outage to affect something already deployed. The entire risk sits in the build, which makes the blast radius easier to reason about than for interpreted languages where dependencies are present on the running machine.

That does mean build pipelines carry the whole cost. CI that starts from a clean environment resolves and downloads everything each run, so an outage lands squarely on the ability to ship. The cheapest mitigation is also the one that speeds up ordinary builds, which is caching the cargo registry between runs. A CI configuration that persists those directories turns most registry problems into a non-event, and the same is true for vendoring dependencies into the repository for projects where builds must work regardless.

Diagnosis is helped by knowing that resolution and download are separate steps against separate systems. Cargo consults the index to work out which versions satisfy your requirements, then fetches the crate files from a content network. A failure at the first step reads as a resolution error, a failure at the second as a download error, and they do not necessarily happen together. Git dependencies add a third path entirely, since a crate pulled from a repository never touches crates.io, and an error there is a GitHub problem wearing a cargo error message.

The last thing worth saying is about the shape of the ecosystem. Crates are immutable once published, which removes a whole category of problem that other registries live with, and it means a build that worked yesterday will resolve to exactly the same code today. When a Rust build starts failing, the change is almost never in the packages themselves, which narrows the search to your own changes, your cache, or the registry's availability.

Frequently asked questions

Is crates.io down right now?

Check the board above; it reflects our own probes against crates.io from all five of our regions, refreshed every couple of minutes. That is the host cargo resolves against, so it is the reading that matters when a build cannot fetch dependencies.

My cargo build is failing to fetch dependencies. Is crates.io down?

Read the error first, since several unrelated causes look alike. A timeout or connection reset against crates.io or its download host points at the registry or the network path; a message that a crate version cannot be found points at your Cargo.toml; and a git-related error points at a dependency pulled from a git repository rather than from the registry at all.

Does a crates.io outage break my running application?

No. A Rust binary is compiled and statically linked, so once it is built it has no relationship with the registry whatsoever. What an outage stops is compiling something new, which affects CI, container builds, and any developer starting from a cold cache.

Why does my build work locally but fail in CI?

Because your machine builds from a warm cargo registry cache while CI usually starts empty. During a partial outage that difference decides who sees the failure, which makes it look like a CI problem rather than a registry one. Caching the cargo registry and git directories between CI runs both speeds builds up and removes this class of failure.

Can I keep building during a registry outage?

Yes, if the crates you need are already in your local cargo cache or vendored into the project. Cargo can build entirely offline when everything it needs is present, and vendoring dependencies into the repository makes that reliable for teams whose builds cannot wait for a registry to recover.