# crates.io status

> Is crates.io down? Live status for the Rust package registry, uptime history, and per-region response times from our own probes on three continents.

Published: 2026-08-31 | Canonical: https://yoping.me/status/crates-io

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/crates-io. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.