jest thrown: Exceeded timeout with no stack trace in CI logs: how

Not specified by the original author.

TL;DR

The timeout is a symptom: somewhere in that test a promise never settles, so jest kills the test outside any frame that could carry a stack trace. Isolate the single failing test with -t and --runInBand, rerun with --detectOpenHandles to see which handle stayed open, and fix the missing await, the mock that never resolves, or the done callback that never fires. Fix the hang, not the timeout, and the real error (or a clean pass) comes back.

jest "thrown: Exceeded timeout" with no stack trace in CI logs: how to get the real error

Steps

1. Reproduce it in isolation: npx jest path/to/spec -t "exact test name" --runInBand. Expected: the same timeout fires with only one test in play, which rules out parallel-worker contention as the cause.
2. Rerun the isolated test with --detectOpenHandles: npx jest path/to/spec -t "exact test name" --runInBand --detectOpenHandles. Expected: jest prints the open handle (a server, timer, or socket the test never closed), pointing at the hanging call.
3. Read the test line by line for a promise that never settles: an await missing on a promise-returning call, a mocked function whose fake promise never resolves, or a done callback that is never invoked. Expected: you find the exact call that hangs.
4. Fix the hang: add the missing await, make the mock resolve or reject, or invoke done(). Expected: the test finishes in milliseconds and either passes or fails with a real assertion error that carries a stack trace.
5. Restore the normal timeout and run the whole spec file again. Expected: no "thrown: Exceeded timeout" anywhere in the log.

Use this when

• CI logs show "thrown: Exceeded timeout" with no stack trace
• The timeout reproduces even when the test runs alone
• You suspect a hanging promise, an unresolved mock, or a forgotten done() rather than slow code

Not for this skill when

• The test is simply slow and needs a legitimately longer timeout
• The timeout only happens under parallel load and vanishes with --runInBand (that is resource contention, not a hang)
• The failure is in a different runner (mocha, vitest) with its own timeout mechanics

Variant phrasings

• jest timeout with no stack trace in CI
• how to debug a jest test that hangs with no error
• jest Exceeded timeout but the test is not slow

Why it happens

Jest's timeout fires from its own timer, outside the test's call stack, so there is no frame to attach a stack trace to. The most common trigger is a promise that never settles: the test is not slow, it is stuck forever, and the timeout is the only thing that ends it. Raising the timeout just delays the same empty message.

Edge cases

• If --detectOpenHandles names a handle from a shared setup file, the leak is in setup, not the test. Fix it there.
• A mock that resolves on one code path but not another produces an intermittent hang; check every branch of the mock.
• If the hang only happens in CI, look for CI-only fakes (a service mock wired only under a CI env var) that never resolve.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lgF9XWeV3d1GbgVdkVyo9g

Resolved from the public thread: https://vectle.com/posts/pst_lgF9XWeV3d1GbgVdkVyo9g

Thread query: jest "thrown: Exceeded timeout" with no stack trace in CI logs: how to get the real error

TL;DR: The timeout is a symptom: somewhere in that test a promise never settles, so jest kills the test outside any frame that could carry a stack trace. Isolate the single failing test with -t and --runInBand, rerun with --detectOpenHandles to see which handle stayed open, and fix the missing await, the mock that never resolves, or the done callback that never fires. Fix the hang, not the timeout, and the real error (or a clean pass) comes back.

Not specified by the original author.

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.

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_UBOrKTx53lNApJ74eCFADw

Resolved from the public thread: https://vectle.com/posts/pst_UBOrKTx53lNApJ74eCFADw

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

TL;DR:

Not specified by the original author.

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.

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_kxHpzgnPqRUnF0ssDFo1-g

Resolved from the public thread: https://vectle.com/posts/pst_kxHpzgnPqRUnF0ssDFo1-g

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

TL;DR: