What causes "Failed to fetch ${url}, too many retries" in vercel/next.js?

curl the URL manually to see the actual status/body.

Failed to fetch ${url}, too many retries

Error message

Failed to fetch ${url}, too many retries

What it means

Thrown by genRetryableRequest after 10 consecutive failed attempts to fetch a URL via genAsyncRequest. Each attempt can fail due to a network error, a non-200 status code, or a response error event. The wrapper swallows per-attempt errors and only surfaces this aggregate message once retries are exhausted, so no per-attempt detail is retained.

Source

Thrown at bench/vercel/gen-request.js:13

import https from 'https'
import timer from '@szmarczak/http-timer'

// a wrapper around genAsyncRequest that will retry the request 5 times if it fails
export async function genRetryableRequest(url) {
  let retries = 0
  while (retries < 10) {
    try {
      return await genAsyncRequest(url)
    } catch (err) {}
    retries++
  }
  throw new Error(`Failed to fetch ${url}, too many retries`)
}

// a wrapper around http.request that is enhanced with timing information
async function genAsyncRequest(url) {
  return new Promise((resolve, reject) => {
    const request = https.get(url)
    timer(request)
    request.on('response', (response) => {
      let body = ''
      response.on('data', (data) => {
        body += data
      })
      response.on('end', () => {
        if (response.statusCode !== 200) {
          reject(new Error(`Failed to fetch ${url}`))
        }
        resolve({
          ...response.timings.phases,

View on GitHub (pinned to 0ae8c72462)

Solutions

curl the URL manually to see the actual status/body.
Wait for the deployment to finish provisioning and retry.
Verify the URL is correct and the deployment is healthy.
If intermittent, the 10-retry cap may be too low under heavy CI load — increase the retry count or add backoff.

Example fix

// before: fixed 10 retries, no backoff
while (retries < 10) { ... }

// after: add delay between retries
while (retries < 10) {
  try { return await genAsyncRequest(url) } catch {}
  await new Promise(r => setTimeout(r, 500 * retries))
  retries++
}

Defensive patterns

Strategy: retry

Validate before calling

// Validate the URL is reachable before entering the retry loop
async function isReachable(url: string): Promise<boolean> {
  try { const r = await fetch(url); return r.ok } catch { return false }
}
if (!(await isReachable(url))) {
  throw new Error(`${url} is not reachable; check the deployment before retrying`)
}

Type guard

null

Try / catch

try {
  return await genRetryableRequest(url)
} catch (e) {
  // Inspect the deployment status; the message gives no per-attempt detail
  throw new Error(`${(e as Error).message} — verify deployment is healthy: ${url}`)
}

Prevention

Confirm the deployment URL is correct and healthy before benchmarking.
Add exponential backoff between retries to survive transient failures.
Increase the retry cap for flaky CI networks.

When it happens

Trigger: The target deployment URL is unreachable (DNS, connection refused, TLS); the endpoint returns non-200 (404, 500, 502) for every attempt; the Vercel deployment is still cold/provisioning and timing out; rate limiting returns non-200 repeatedly.

Common situations: Benchmarking a Vercel deployment that is not yet ready; wrong/typo deployment URL; the deployment crashed (forceCrash mode); network egress blocked from the runner.

Related errors

AI-assisted analysis of vercel/next.js@0ae8c72462 (2026-08-06). Data as JSON: /api/errors/9cac86be04d9eb0a. Report an issue: GitHub.