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.

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.