What causes "Server did not become ready within ${timeoutMs}ms" in vercel/next.js?

Increase --timeout-ms (e.g. 60000) for slow or cold-start environments.

Server did not become ready within ${timeoutMs}ms

Error message

Server did not become ready within ${timeoutMs}ms

What it means

Thrown by waitForServerReady when the server does not answer the readiness probe with a 2xx within the configured timeout (default 30000ms via --timeout-ms). The loop polls every 200ms; if none succeed in time, the server is too slow or unreachable and measurement would be unreliable.

Source

Thrown at bench/render-pipeline/client-trace.ts:247

    // Without this check, a server that dies on startup (e.g. EADDRINUSE
    // against a stale server on the same port) is indistinguishable from
    // a slow one — worse, a 200 from whatever else owns the port would
    // pass, and the run would silently measure the wrong server.
    if (serverDied?.()) {
      throw new Error(
        `Server process exited before becoming ready (is port already in use?)`
      )
    }
    try {
      const response = await fetch(url, { cache: 'no-store' })
      await response.arrayBuffer()
      if (response.ok) return
    } catch {
      // server not ready yet
    }
    await sleep(200)
  }
  throw new Error(`Server did not become ready within ${timeoutMs}ms`)
}

// The death check alone is racy on a contested port: a stale server can
// answer the readiness probe before our child fails to bind, and the run
// would silently measure the wrong server.
async function assertPortFree(port: number): Promise<void> {
  const controller = new AbortController()
  const timeout = setTimeout(() => controller.abort(), 1000)
  try {
    await fetch(`http://127.0.0.1:${port}/`, {
      cache: 'no-store',
      signal: controller.signal,
    })
  } catch {
    return
  } finally {
    clearTimeout(timeout)
  }

View on GitHub (pinned to 0ae8c72462)

Solutions

Increase --timeout-ms (e.g. 60000) for slow or cold-start environments.
Verify the server is listening on the exact host:port the probe uses (127.0.0.1:PORT).
Pre-warm the server (curl it once) before tracing.
Check the server logs for what is taking long (compile, middleware, data fetch).

Example fix

// before
--timeout-ms=30000
// after
--timeout-ms=90000

Defensive patterns

Strategy: retry

Validate before calling

// Choose a timeout appropriate to the environment
const timeoutMs = process.env.CI ? 90_000 : 30_000

Type guard

null

Try / catch

null

Prevention

Raise --timeout-ms on slow/CI machines or cold first compiles.
Pre-warm the server with a curl before tracing.
Confirm the server binds the exact host:port being probed.

When it happens

Trigger: A cold/first build taking longer than the timeout; the server bound to a different host/port than probed; network proxy intercepting; very slow machine; the readiness route is slow (e.g. heavy middleware).

Common situations: Default 30s too short for a slow CI machine or first cold compile; the URL host mismatches (127.0.0.1 vs localhost); a dev server doing a large initial compile.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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