Bundler 5xx / Network Failure Fetching from rubygems.org

By Daniel Zoghalchali·Latchkey

Bundler's connection to the gem source stalled, reset, or returned a 5xx. These are transient network failures on the source side and almost always succeed on retry.

What this error means

bundle install fails partway through fetching gem metadata or a .gem file with a timeout, a connection reset, or an HTTP 500/503 from rubygems.org. Re-running the job usually works with no change - the hallmark of a transient source issue.

Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch
specs from https://rubygems.org/ due to underlying error <Net::OpenTimeout: ...>

Bundler::HTTPError: Could not fetch specs from https://rubygems.org/

Common causes

Transient source outage or rate limiting

A brief rubygems.org hiccup, a CDN blip, or rate limiting returns a 5xx or times out. Nothing is wrong with your Gemfile.

Flaky runner network

A connection reset or DNS hiccup on the runner interrupts the fetch mid-download, especially on busy or shared CI networks.

How to fix it

Raise Bundler retries and timeout

bundle install --retry 5 --jobs 4
# or persist
bundle config set --global retry 5

Cache the gems between runs

Caching the installed bundle means most gems are already local, so a flaky source matters far less.

- uses: actions/cache@v4
  with:
    path: vendor/bundle
    key: gems-${{ hashFiles('Gemfile.lock') }}

Use a closer or internal mirror

1. Point Bundler at a geographically closer mirror with bundle config mirror.rubygems.org.
2. Host an internal gem mirror (Gemstash, Artifactory) for high-volume pipelines.
3. Commit Gemfile.lock so the fetched set is stable and cacheable.

How to prevent it

• Cache vendor/bundle keyed on Gemfile.lock.
• Set a global retry count so transient source errors self-recover.
• Use an internal mirror to reduce dependence on public rubygems.org.

Frequently asked questions

Related guides

References

• Bundler documentation
• GitHub Actions documentation