Global Timeout Configuration vs Per-Request Overrides for Latency Constraints

When designing performance tests in k6, managing request timeouts is essential to prevent hanging VU (Virtual User) iterations and to accurately measure service degradation. k6 provides two primary methods for controlling these durations: a global timeout property within the options object and granular overrides passed directly into individual http.request calls.

The trade-off involves balancing configuration simplicity against the need for specific latency thresholds across different endpoints. While a global setting ensures a consistent baseline for all traffic, certain legacy endpoints or heavy reporting queries may require longer windows to avoid false-positive failures, whereas critical API paths require strict, shorter timeouts to simulate real-world client behavior.

Technical Constraints

• Global options apply to all requests unless explicitly overridden.
• Timeouts are defined in milliseconds.
• k6 marks timed-out requests as failures in the final metrics.

In a scenario with mixed-latency endpoints, should the architecture rely on a conservative global timeout with targeted overrides for slow requests, or a strict global timeout with expanded windows for specific calls? Which approach provides more maintainable scripts when scaling the number of tested endpoints?