Karma Configuration Deep Dive

Options That Matter as Projects Grow

A minimal karma.conf.js works fine for a small suite, but as test count and CI complexity grow, a handful of additional options become important: controlling log verbosity, tuning timeouts so CI doesn't hang on a stuck browser, and limiting how many browsers run concurrently on resource-constrained machines.

config.set({
  logLevel: config.LOG_INFO,
  colors: true,
  port: 9876,
  browserNoActivityTimeout: 60000,
  browserDisconnectTimeout: 10000,
  browserDisconnectTolerance: 1,
  concurrency: 2
});

None of these are required for a tiny suite, but each solves a real, specific problem as suites and CI environments grow.

Timeout and Concurrency Options

browserNoActivityTimeout: 30000   // ms of silence before Karma kills a browser
browserDisconnectTimeout: 2000    // ms to wait after a disconnect before giving up
browserDisconnectTolerance: 0     // number of disconnects tolerated before failing
captureTimeout: 60000             // ms allowed for a browser to launch/connect
concurrency: Infinity              // max browsers run in parallel

• browserNoActivityTimeout is the single most useful setting for CI jobs that hang mid-run.
• Lower concurrency on shared/limited CI runners to avoid resource contention between browser processes.
• captureTimeout matters most on slow CI machines where a headless browser can be slow to boot.
• browserDisconnectTolerance above 0 allows an occasional flaky disconnect without failing the whole run.

Configuration Options Cheat Sheet

Secondary options worth knowing once your suite grows beyond the basics.

Controlling Log Verbosity

logLevel accepts one of Karma's built-in constants, exposed on the config object passed into your config function. Raising it to config.LOG_DEBUG is one of the fastest ways to understand exactly what Karma is doing when something behaves unexpectedly.

config.set({
  logLevel: config.LOG_DEBUG
});

// Available levels, from quietest to noisiest:
// config.LOG_DISABLE
// config.LOG_ERROR
// config.LOG_WARN
// config.LOG_INFO   (default)
// config.LOG_DEBUG

CI-Safe Timeout Defaults

CI machines are frequently slower and more resource-constrained than local development machines, so timeout values tuned for a fast laptop can cause flaky failures in CI. It's common to configure more generous timeouts specifically for CI runs.

const isCI = !!process.env.CI;

config.set({
  browserNoActivityTimeout: isCI ? 120000 : 30000,
  captureTimeout: isCI ? 120000 : 60000
});

Doubling or tripling timeouts for CI is a common, low-risk fix for flaky 'browser disconnected' failures.

Common Mistakes

• Leaving default timeouts unchanged on slow CI runners, causing intermittent 'no activity' failures.
• Setting concurrency too high on shared CI infrastructure and starving other jobs of resources.
• Ignoring logLevel entirely when debugging a launch failure, instead of temporarily raising it to LOG_DEBUG.
• Not forwarding browser console output (client.captureConsole) when a test failure needs more context than the assertion message provides.

Key Takeaways

• Secondary configuration options solve real problems that appear as suites and CI environments scale up.
• Timeout settings (browserNoActivityTimeout, captureTimeout) are the most common fix for CI-specific flakiness.
• logLevel set to config.LOG_DEBUG is the fastest way to diagnose an unexpected startup or launch issue.
• concurrency should be tuned deliberately based on the CI machine's actual resource limits.