Resource limit exceeded

The process exceeded an OS-enforced resource limit such as the maximum number of threads or processes.

resource-limits high confidence runtime

Matched signals

  • ulimit
  • resource temporarily unavailable
  • cannot create thread
  • system limit

Resource limit exceeded

What this failure means

The process exceeded an OS-enforced resource limit such as the maximum number of threads or processes.

Symptoms

Faultline looks for one or more of these log fragments:

ulimit
resource temporarily unavailable
cannot create thread
system limit

Diagnosis

The process exceeded an OS-enforced resource limit such as the maximum number of threads or processes.

Fix steps

  1. Determine which limit was hit first (ulimit -a, open files, pids, threads) so you change the right control instead of raising all limits blindly.
  2. Find and fix the leak or bursty workload causing the limit breach, such as file descriptors left open, unbounded goroutines, or too many worker processes.
  3. Reduce test or worker parallelism to lower peak file descriptor, process, and thread usage.
  4. If the workload is legitimate, raise the specific runner or container limit that failed, for example ulimit -n 65536 for open files.
  5. Capture diagnostics during the failing step (lsof, process counts, runtime metrics) so you can see whether usage is steadily leaking or spiking.

Validation

  • Re-run the failing workflow step.
  • Confirm the original failure signature for Resource limit exceeded is gone.

Why it matters

CI environments apply ulimits to prevent runaway processes from consuming all system resources. Tests or build tools that create many file handles, threads, or subprocesses without cleaning them up can hit these limits.

Prevention

  • Run long-lived integration tests under the same runner limits used in CI so leaks show up before release branches.
  • Always close files, sockets, and database connections promptly and prefer shared client pools over creating new clients per request.
  • Cap test and worker parallelism relative to runner size instead of assuming local developer hardware matches CI capacity.
  • Profile file descriptor, thread, and process usage over time to catch slow leaks before they reach hard limits.

How Faultline detects it

Use faultline explain resource-limits to see the full playbook.

faultline analyze build.log
faultline explain resource-limits

Generated from playbooks/bundled/log/runtime/resource-limits.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.