k6 error: request timed out during load test - how to tell server slowness from client limits

k6 error: request timed out during load test - how to tell server slowness from client limits

TL;DR

k6 timeouts can mean the server is slow or the load generator itself is saturated. Check the generator first: CPU, open sockets, and whether timeouts cluster at the generator. If the generator is healthy, the timeouts are real server slowness and the fix is on the server.

k6 error: request timed out during load test

Steps

1. Watch the load generator's own resources during the test: CPU, memory, and socket count. Expected: A saturated generator shows high CPU or socket exhaustion alongside the timeouts.

2. Compare timeouts against server-side latency metrics for the same window. Expected: If the server's p99 is fine while k6 reports timeouts, the client is the bottleneck.

3. Reduce VUs on one generator and add a second generator; if timeouts drop, the first generator was the limit. Expected: Timeouts scale with per-generator load, not total load.

4. Check for client-side connection reuse problems: k6 reuses connections per VU, but TLS handshakes on new connections can spike under ramp-up. Expected: Timeouts cluster during ramp, not steady state.

5. Once the generator is cleared, treat remaining timeouts as real: profile the server path for the timed-out endpoints. Expected: Server-side fixes move the timeout rate, proving the measurement is now honest.

When to use

• k6 reports request timeouts under load
• you need to blame the server or the generator
• timeouts do not match server-side latency metrics

When not to use

• timeouts happen at 1 VU (that is a server or network problem, not a generator limit)
• the error is a k6 script error (check the JS first)
• the target is unreachable at all (connectivity, not load)

Tool compatibility

• k6 (any recent version)
• applies to httpreqfailed with timeout reason

Variant phrasings

• "k6 request timed out load test"
• "k6 timeouts but server is fine"
• "k6 client side bottleneck vs server slowness"

Why it happens

A load generator is itself a system under test. Each VU consumes CPU, sockets, and memory; when the generator saturates, requests queue client-side and hit k6's timeout without ever stressing the server. The timeout metric cannot tell the two apart, so you have to measure the generator too.

Edge cases

• cloud runners have their own bandwidth caps; a timeout storm from one region can be the runner's NIC
• timeouts: in k6 options sets the per-request deadline; a too-tight value manufactures failures
• TLS session resumption differences between runs can shift handshake cost and look like server variance

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-TvaMCyPp5QI66FxDYNVhA