RubyGems status

How we check RubyGems

We watch rubygems.org 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 host that bundler and the gem command resolve against, which is what decides whether an install or a deploy can proceed. The gem files themselves are served through a content network, so checking downloads alone would miss the dependency resolution failures that stop a build before anything is fetched.

What is RubyGems?

RubyGems is the package registry for Ruby, and rubygems.org is where essentially every gem is published and fetched from. Bundler resolves a Gemfile against it, deploys install from it, and a Rails application of any size depends on a few hundred gems that each came from there. Like most registries it is infrastructure that nobody thinks about until it stops answering.

The consequences of an outage are narrower than the initial panic suggests, and it is worth being clear about the boundary. Applications already running are untouched: their gems are installed on the server or inside the container image, and nothing at runtime reaches back to the registry. What stops is installing. CI fails at bundle install, container builds fail at the same step, a developer setting up the project cannot finish, and any deploy that installs dependencies as part of its process stops partway. Production is fine, and changing production is not possible.

Deploy pipelines are where this bites hardest, and the reason is worth understanding. A Gemfile.lock guarantees which versions you get, not that those versions are already present wherever the deploy runs. If the deployment step fetches gems, it needs the registry, and an unchanged commit that deployed cleanly an hour ago can fail now for reasons that have nothing to do with the code. Vendoring dependencies or persisting the bundle path between builds removes the registry from the critical path entirely, and teams that have done it barely notice registry incidents.

Diagnosis is complicated by how many bundler failures are not registry failures. A version conflict that bundler cannot resolve produces a long and alarming message that has nothing to do with availability. A private gem source with an expired token stalls on that source while the public registry answers instantly. A corporate proxy intercepting TLS produces a certificate error that reads like a network outage. Reading the actual error before checking a status page saves more time than the reverse.

The wider observation is one this whole section of the site keeps arriving at. Language package registries are single points of failure that almost no team treats as such, largely because they are reliable enough that the question never comes up. The cheap insurance is caching what you already depend on. The expensive version is discovering, during an incident, that a routine deploy cannot be completed.

Frequently asked questions

Is RubyGems down right now?

Check the board above; it reflects our own probes against rubygems.org from all five of our regions, refreshed every couple of minutes. That is the host bundler talks to, so it is the reading that matters for a failing bundle install.

My bundle install is hanging. Is RubyGems down?

Check the error rather than the symptom, because bundler hangs for several unrelated reasons. A timeout against rubygems.org points at the index or the network; a message about being unable to find a compatible version points at your Gemfile rather than the registry; and a private gem source with expired credentials will stall on that source alone while rubygems.org is perfectly healthy.

Does a RubyGems outage affect my running application?

No. Gems already installed on the server or bundled into a container image keep working, because nothing at runtime contacts the registry. What breaks is anything that installs afresh, which means CI, container builds, a new developer setting up the project, and deploys that run bundle install as a step.

Why did my deploy fail when my Gemfile did not change?

Usually because the deploy resolved dependencies again and could not reach the registry at that moment. A Gemfile.lock pins versions, but bundler still needs to fetch any gem not already present in the deployment's cache, so an identical commit can deploy successfully in the morning and fail in the afternoon. Vendoring gems or caching the bundle path in CI removes that dependency from the deploy path.

Can I keep deploying during a RubyGems outage?

Yes, if your gems are already cached or vendored where the deploy runs. Bundler will use a local cache when one is available, so teams that vendor dependencies or persist the bundle directory between builds ride through outages that stop everyone else. That is worth setting up before you need it, since arranging it during an incident is not possible.