{"record":{"id":"02493a1327e8ccf4","repo":"vercel/next.js","slug":"server-did-not-become-ready-within-timeoutms-ms-02493a","errorCode":null,"errorMessage":"Server did not become ready within ${timeoutMs}ms","messagePattern":"Server did not become ready within (.+?)ms","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"bench/render-pipeline/client-trace.ts","lineNumber":247,"sourceCode":"    // Without this check, a server that dies on startup (e.g. EADDRINUSE\n    // against a stale server on the same port) is indistinguishable from\n    // a slow one — worse, a 200 from whatever else owns the port would\n    // pass, and the run would silently measure the wrong server.\n    if (serverDied?.()) {\n      throw new Error(\n        `Server process exited before becoming ready (is port already in use?)`\n      )\n    }\n    try {\n      const response = await fetch(url, { cache: 'no-store' })\n      await response.arrayBuffer()\n      if (response.ok) return\n    } catch {\n      // server not ready yet\n    }\n    await sleep(200)\n  }\n  throw new Error(`Server did not become ready within ${timeoutMs}ms`)\n}\n\n// The death check alone is racy on a contested port: a stale server can\n// answer the readiness probe before our child fails to bind, and the run\n// would silently measure the wrong server.\nasync function assertPortFree(port: number): Promise<void> {\n  const controller = new AbortController()\n  const timeout = setTimeout(() => controller.abort(), 1000)\n  try {\n    await fetch(`http://127.0.0.1:${port}/`, {\n      cache: 'no-store',\n      signal: controller.signal,\n    })\n  } catch {\n    return\n  } finally {\n    clearTimeout(timeout)\n  }","sourceCodeStart":229,"sourceCodeEnd":265,"githubUrl":"https://github.com/vercel/next.js/blob/0ae8c72462952df163f1b1e0726641bc5b40dc93/bench/render-pipeline/client-trace.ts#L229-L265","documentation":"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.","triggerScenarios":"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).","commonSituations":"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.","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)."],"exampleFix":"// before\n--timeout-ms=30000\n// after\n--timeout-ms=90000","handlingStrategy":"retry","validationCode":"// Choose a timeout appropriate to the environment\nconst timeoutMs = process.env.CI ? 90_000 : 30_000","typeGuard":"null","tryCatchPattern":"null","preventionTips":["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."],"tags":["server","timeout","startup"],"analyzedSha":"0ae8c72462952df163f1b1e0726641bc5b40dc93","analyzedAt":"2026-08-06T19:44:29.143Z","schemaVersion":2},"datasetVersion":"2026-08-07T02:17:10.218Z"}