Skip to content
Latchkey

pytest-timeout "Timeout >Ns" - Test Killed for Hanging in CI

pytest-timeout killed a test that ran longer than its allowed time and dumped the stack at the moment it was interrupted. Either the test genuinely hangs (a blocking call with no timeout) or the limit is too tight for a legitimately slow test.

What this error means

A test fails with Failed: Timeout >Ns and a thread dump showing where it was stuck - frequently inside a socket read, a lock acquire, or join(). It may be flaky, tripping only when an external call is slow.

pytest output
tests/test_worker.py::test_consume FAILED
E   Failed: Timeout >30.0s
~~~~~~~~~~~~~~~~~~~~~ Stack of MainThread ~~~~~~~~~~~~~~~~~~~~~
  File ".../socket.py", line 705, in readinto
    return self._sock.recv_into(b)

Common causes

A genuine hang in the test or code

A blocking I/O call without its own timeout, a deadlock between threads, or an unjoined process can hang forever; pytest-timeout interrupts it at the limit.

Timeout too tight for a slow test

A legitimately slow integration test (large fixture build, real network) exceeds a global timeout meant for fast unit tests.

How to fix it

Find the hang from the stack dump

  1. Read the dumped stack - it shows exactly where the test was stuck when killed.
  2. Add a timeout to the blocking call itself (socket, requests, lock acquire).
  3. For deadlocks, fix the lock ordering rather than extending the timeout.

Raise the limit for known-slow tests

Keep a tight global default and override per-test where slowness is expected.

Python
import pytest

@pytest.mark.timeout(120)
def test_large_integration():
    ...

How to prevent it

  • Give every blocking call (sockets, requests, locks) its own explicit timeout.
  • Keep a tight global timeout and raise it only on specific slow tests.
  • Treat repeated timeouts as a hang to fix, not flakiness to retry around.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →