Global Timeout Configuration vs Per-Request Overrides for Latency Constraints

Answer to the Core Question

When you have a mix of fast and slow endpoints, the most maintainable approach is to set a conservative global timeout (longer than the fastest expected latency) and apply per‑request overrides only to the truly critical, latency‑sensitive paths. This keeps the majority of requests governed by a single value while still protecting the most important calls from false failures.

Confirmed Facts (k6 behavior)

• Setting options.timeout establishes a baseline that applies to every HTTP request unless an override is supplied.
• An override passed in http.request(..., { timeout: ms }) takes precedence over the global value for that specific call.
• k6 records timed‑out requests as failures in the http_failures metric, affecting overall pass/fail status.
• All internal k6 traffic (e.g., metrics export) also respects options.timeout, so a too‑short global timeout can break the test harness itself.

Why a Conservative Global Timeout Wins

• Reduced boilerplate: Only a handful of critical endpoints need explicit timeouts, keeping the script concise.
• Lower risk of accidental failures: If a new endpoint is added without an override, it inherits the safe global value, avoiding unintended timeouts.
• Consistent metrics: All non‑critical traffic behaves the same, simplifying interpretation of latency trends.

When a Strict Global Timeout Might Be Needed

• If the majority of endpoints are genuinely latency‑sensitive and you cannot afford any delay, a strict global timeout with many overrides may be justified.
• However, as the number of endpoints grows, the maintenance burden (listing overrides for each one) outweighs the benefits.

Practical Steps for Your Script

1. Choose a global timeout that covers the slowest *expected* endpoint but is still shorter than the maximum acceptable latency for most traffic. For example, options.timeout = 8000 (8 s).

2. Identify the critical paths that must fail faster (e.g., /orders/create, /payments/charge) and add overrides:

   http.get('https://api.example.com/orders/create', { timeout: 2000 })

3. Document the list of overridden endpoints in a separate file or comment block so future contributors can see which paths have special limits.

4. Run the test and inspect http_reqs and http_failures to confirm overrides are respected.

5. When adding new endpoints, default to the global timeout unless there is a clear business or technical reason to override.

Missing Diagnostic Detail

To fine‑tune the recommendation, could you share how many endpoints you consider “critical” versus “slow”? Knowing the ratio helps decide whether a stricter global timeout with many overrides is truly necessary.