k6 "level=error ... Request Failed" during the run in CI

By Kaveh Alemi·Latchkey

k6 logs "Request Failed" for each request that did not complete: a timeout, a connection reset, or a transport error. A burst of these under load usually means the target or the load generator hit a limit, not that the script is wrong.

What this error means

The run log fills with "level=error msg=Request Failed error=..." lines and http_req_failed climbs. The error text (i/o timeout, connection reset by peer, EOF) points at the cause.

WARN[0012] Request Failed  error="Get \"http://app/\": read tcp 10.0.0.5->10.0.0.9: i/o timeout"
level=error msg="Request Failed" error="Post \"http://app/login\": EOF"

Common causes

The target is saturated or resetting connections

Under the VU load the service times out, returns EOF, or resets connections because its worker pool, file descriptors, or upstream is exhausted.

Load generator runs out of local resources

The runner exhausts ephemeral ports or file descriptors, so k6 itself cannot open new sockets and reports transport errors.

How to fix it

Distinguish target errors from generator limits

1. Read the error text: i/o timeout and 5xx point at the target; "cannot assign requested address" points at the generator.
2. Reduce VUs or ramp if the generator is the bottleneck.
3. Raise file-descriptor limits on the runner for high-concurrency runs.

ulimit -n 65535
k6 run --vus 200 --duration 60s script.js

Set a request timeout and handle errors in the script

Give requests an explicit timeout and check the result so transient errors are measured, not crashes.

import http from 'k6/http';
const res = http.get('http://app/', { timeout: '10s' });

How to prevent it

• Raise ulimit -n on the runner before high-concurrency runs.
• Ramp VUs gradually so the target is not slammed cold.
• Set explicit request timeouts so slow responses are counted, not fatal.

Frequently asked questions

Related guides

References

• GitHub Actions documentation