CI: Buildkite agents are lost during parallel Jest config runs
Author: tylersmalleyCreated Sep 17, 2026Updated Sep 18, 2026
LabelsTeam:Operations
Summary
Buildkite agents are being lost while a single Jest job runs up to three Jest config processes concurrently. Each process has a 4096 MB old-space limit; on the 16 GB n2-standard-4 agents, their aggregate demand plus parent-process and native overhead can exhaust host memory.
The failed attempt exits with -1, the agent transitions to lost, and Buildkite automatically retries the job. The job log ends abruptly without a Jest failure summary or an OOMKilled line because the agent itself disappears. This can leave the final build green while masking the failed attempt and adding substantial CI time.
Each Jest config process uses --runInBand; the parallelism is between config suites, not between test files within a suite.
Examples
- PR build 503826, Jest shard #3 — failed attempt: exited
-1; agent becamelost; automatically retried. This shard includedx-pack/platform/plugins/shared/maps/jest.config.js. - PR build 502056, Jest shard #10 — failed attempt: exited
-1; agent becamelost; automatically retried. - PR #290963, whose CI history contains both affected builds.
Impact
- Jest jobs intermittently lose their Buildkite agent before producing a normal test result.
- Automatic retries obscure the failure in the final build status.
- Completed configs must be recovered from checkpoints and remaining work rerun.
- PR and merge validation take longer and consume additional CI capacity.
Source: elastic/kibana