Choosing between browserNoActivityTimeout and captureTimeout for CI flake reduction

Short answer

browserNoActivityTimeout is the primary lever for preventing indefinite CI hangs. It watches the test runner after the browser has connected. captureTimeout only affects startup and should be set long enough for the slowest agent but not so high that launch failures are hidden.

Why the two timeouts behave differently

• captureTimeout (default ~60s in Karma 6) is the maximum time Karma will wait for a browser to launch and report ready. It does not kill a browser that is already running but stalled.
• browserNoActivityTimeout (default ~10s in Karma 6) is the maximum period of inactivity after the browser has started. If no messages are received from the browser during this window, Karma terminates the session, which stops hung tests but can also cut off legitimately slow tests.

Version-specific note

From Karma 6 onward the defaults changed: browserNoActivityTimeout was lowered to 10s and captureTimeout to 60s. If you upgraded from an older release, re-examine both values; a configuration that once worked may now be too aggressive.

Step-by-step validation plan

1. Baseline run: Execute your full test matrix on a clean CI agent with the current defaults. Record:
   • Browser start-up latency (time from karma start to browser ready)
   • Longest test duration in the unit suite
   • Any observed hangs or timeouts
2. Set captureTimeout:

   Choose a value that exceeds the slowest observed start-up by ~30%. Common practice is 90–120s on resource-constrained agents.

   captureTimeout: 120000 // 120s

3. Set browserNoActivityTimeout:

   Start with 30s. This is a safe compromise: it kills a stalled test quickly but still allows slow integration tests that legitimately wait (e.g., 20s async call) to finish.

   browserNoActivityTimeout: 30000 // 30s

4. Unit-suite sanity check:

   Run the unit suite again. If no failures appear and the job finishes within the expected window, the new timeouts are acceptable for fast tests.

5. Integration-suite check:

   Run the integration suite. Verify that:

   • No legitimate slow test is marked as failed due to the timeout.
   • Any truly hung test is terminated within browserNoActivityTimeout.

6. Iterative tuning:

   If integration tests still fail unnecessarily, increase browserNoActivityTimeout in 5s increments until the failure rate drops, then re-run the unit suite to ensure no new flakiness is introduced.

Diagnostic detail that can change the recommendation

What is the longest observed browser start-up time on your CI agents? If it regularly exceeds 90s, raise captureTimeout accordingly; otherwise keep it low to surface startup problems early.

Practical verification snippet

To confirm that browserNoActivityTimeout works, add a test that blocks the message loop for 60s:

it('blocks message loop', async () => {
  await new Promise(resolve => setTimeout(resolve, 60000));
});

When run with browserNoActivityTimeout: 30000, the job should terminate after ~30s, proving the setting is effective.

Summary

For deterministic CI termination, prioritize browserNoActivityTimeout and keep captureTimeout just long enough for the slowest browser to launch. Validate with a two-phase test run and adjust incrementally, always checking that fast unit tests stay fast while slow integration tests are not prematurely aborted.