Hugging Face status

How we check Hugging Face

We watch huggingface.co 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 hub host that libraries resolve models and datasets against, because that is the request a training job or a container build makes before anything else can happen. Inference endpoints and Spaces run on separate infrastructure with their own availability, which this reading deliberately does not claim to cover.

What is Hugging Face?

Hugging Face is the hub where machine learning models, datasets, and demonstration applications are published and fetched. In practice it has become the package registry of the machine learning world: a line of code naming a model pulls the weights from the hub, and an enormous amount of research code, production inference, and training tooling assumes that call will succeed.

The dependency behaves like other registries in the way that matters most. Weights already downloaded, whether cached on a machine or baked into a container image, keep working when the hub is unreachable, because inference does not call back to check them. What an outage stops is fetching. New deployments that download at startup fail, autoscaling onto a fresh node fails, CI jobs that pull a model during a build fail, and a researcher starting an experiment cannot begin. Already-serving models carry on untouched.

That distinction has a practical consequence specific to this ecosystem, because the artefacts are so large. Downloading several gigabytes of weights on every container start is slow on a good day and impossible on a bad one, so it is worth building images with the weights included, or mounting a shared cache, well before an incident makes the argument for you. Teams that do this see hub outages as an inconvenience for new work rather than an outage of their inference service.

Access control causes more confusion here than availability does. Gated models require accepting a licence and authenticating, private repositories need a token with the right scope, and models are occasionally renamed, moved, or made private by their authors. Each of these produces an error at download time that reads like a failure and is in fact the hub working correctly. A 401 or 403 is not an outage, and even a 404 is more likely to mean the repository moved than that anything broke.

The last thing worth separating is the platform's several products. Model and dataset downloads, hosted inference endpoints, and Spaces run on different infrastructure and fail independently. An application that uses hosted inference has a different exposure from one that downloads weights and runs them itself, and treating a single indicator as covering both would be misleading. This page watches the hub, which is the piece almost everyone depends on, and the official component breakdown covers the rest.

Frequently asked questions

Is Hugging Face down right now?

Check the board above; it reflects our own probes against the hub from all five of our regions, refreshed every couple of minutes. Inference endpoints and Spaces are separate services, so check the component breakdown on Hugging Face's own status page for those.

My training job cannot download a model. Is that an outage?

Check the error before assuming so, because access rules cause this as often as availability does. Gated models require you to accept their licence and authenticate, private repositories need a token with the right scope, and a model that was renamed or made private returns a not-found error that looks identical to a failure. A 401 or 403 means the hub answered you and declined.

Does an outage stop my already-deployed model from serving?

Not if the weights are already on the machine. A model downloaded into a container image or a local cache keeps serving inference regardless of whether the hub is reachable, because nothing calls back to it at request time. What breaks is anything that fetches fresh, which means new deployments, autoscaling onto a cold node, and CI jobs that download weights during a build.

Why is my model download so slow?

Large weights are large, and the download is bounded by bandwidth and distance rather than by anything being wrong. A multi-gigabyte model pulled across a continent takes as long as it takes, and pulling the same weights on every autoscaling event multiplies that cost. Caching weights in the image or on a shared volume is the standard fix and removes the hub from your startup path.

Do Hugging Face Spaces going down affect the hub?

Not necessarily, they are separate. Spaces run hosted applications on their own infrastructure, and it is normal for them to be degraded while model and dataset downloads work perfectly, or the reverse. The official status page separates the components, which is the right place to look during an incident.