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.
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
- Read the dumped stack - it shows exactly where the test was stuck when killed.
- Add a timeout to the blocking call itself (socket, requests, lock acquire).
- 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.
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.