# RubyGems status

> Is RubyGems down? Live status for rubygems.org, uptime history, and per-region response times measured by our own probes every 2 minutes.

Published: 2026-08-25 | Canonical: https://yoping.me/status/rubygems

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

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/rubygems. 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 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.