Find the slow test and give it its own budget. A Jest timeout on exactly one shard means that shard got more work than the others - one test (or hook) runs long on slow CI hardware and burns the 5 second default while its shard-mates on other machines finish fine. Identify the slowest tests with Jest's timing output, then raise the timeout for the slow ones individually rather than bumping it globally. A global timeout increase makes every future slowdown invisible; a per-test increase documents which tests are known-slow. If one shard is consistently the slow one, rebalance: move a slow suite off it or split the shard.

```text
jest "Exceeded timeout of 5000 ms for a test" only on CI's slowest shard: how to fix
```

## Steps
1. Find the slow tests: run Jest with verbose timing (or check the CI log for the test that was running when the timeout fired). The timeout message names the test - start there.
   Expected: you have named the test that exceeds 5 seconds on CI, and you know its local runtime for comparison.

2. Run that test alone on CI-like hardware (or just time it locally and multiply). If it is slow everywhere, the test needs slimming down - usually a real timer, an unmocked network call, or a huge fixture.
   Expected: you know whether the test is slow everywhere (fix the test) or only on CI (fix the budget).

3. Raise the timeout for that test only, with a comment explaining why it is slow. Keep the suite default at 5 seconds so new slowdowns still get caught.
   Expected: the slow test passes on CI and the default timeout still guards everything else.

4. Check shard balance: if CI splits by file or directory, one shard may hold all the slow suites. Move slow suites across shards or split the heavy shard.
   Expected: shard runtimes are roughly even and no shard is near the timeout wall.

5. Watch for hangs disguised as slowness: a test that takes exactly the timeout every run is probably waiting on something that never resolves - an unresolved promise or a missing mock. That needs a code fix, not a timeout bump.
   Expected: runtimes vary run to run (slow) rather than pinning at exactly the timeout (hanging).

## Use this when

- "Exceeded timeout of 5000 ms for a test" on one CI shard but not others
- a Jest suite that passes locally and on most shards
- you need to separate a slow test from an unbalanced shard

## Not for this skill when

- timeouts that reproduce locally (the test is slow everywhere - slim it down)
- tests that hang at exactly the timeout every run (that is an unresolved promise or deadlock, not slowness)

## Variant phrasings

### jest timeout CI

The general form. Shard-only adds the balance investigation.

### jest test timeout 5000ms

Same error without the shard qualifier. The per-test timeout fix applies either way.

## Why it happens

Jest's default test timeout is 5 seconds, and CI machines are slower and more contended than laptops - shared runners throttle CPU, and parallel shards compete for it. When CI splits the suite across shards, the split is usually by file count, not by runtime, so one shard can inherit several slow suites and cross the timeout while other shards idle. The timeout error names the test that was running when time ran out, which is your starting point - but the fix is about that test's budget or the shard's balance, not about Jest being broken.

## Edge cases

- raising the timeout globally in jest config: tempting, hides every future regression in test speed - scope it per test
- fake timers versus real timers: a test using real setTimeout waits will always be slow - switch to fake timers where the timing is not under test
- detectOpenHandles: use it to find tests that keep handles open and slow down teardown on CI

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IyhAIh58PghH-R4w55rcbA