Ramping VU Configuration Inconsistent After k6 v0.55 Upgrade

Direct Answer

In k6 v0.55, Ramping VU duration parameters are interpreted in seconds by default when no unit suffix is provided. The upgrade from 0.54 does not change this fundamental behavior, but the CLI and web UI may display conflicting units (seconds vs milliseconds) due to internal formatting changes. The rate limiter operates independently from the VU ramping mechanism—it throttles per-VU request rates, not the global VU count progression. However, overlapping configurations can create the appearance of pacing discrepancies.

Confirmed Behavior

• Duration units: Unsuffixed numeric values in ramp stages (e.g., duration: 30) are treated as seconds. Explicit suffixes (30s, 30000ms) are always honored and eliminate ambiguity.
• Rate limiter scope: The rps or iterations rate limiter constrains how fast each VU executes iterations. It does not alter the scheduler's VU ramp-up/down timeline.
• Upgrade impact: v0.55 introduced internal scheduler refinements that can change ramp-step granularity. Scripts relying on implicit second-based durations without explicit units may exhibit different step timing.

Verification Steps

1. Add explicit units to all ramp stages in your script:

   export const options = {
     scenarios: {
       ramp: {
         executor: 'ramping-vus',
         stages: [
           { duration: '30s', target: 50 },
           { duration: '1m', target: 100 },
           { duration: '30s', target: 0 }
         ]
       }
     }
   };

2. Run a short test with metric output to observe actual VU progression:

   k6 run --out json=metrics.json script.js

3. Inspect the vus and vus_max metrics over time in the JSON output or via k6 run --summary-export=summary.json. Confirm the VU count reaches each target at the expected wall-clock time.
4. Temporarily disable rate limiting (remove rps or maxIterations) and re-run. If ramp timing matches expectations without the limiter, the limiter configuration—not the scheduler—is causing the perceived discrepancy.

One Diagnostic Detail Needed

Does your script use a rps (requests per second) or maxIterations rate limiter in the same scenario? If yes, share the exact limiter value and the ramp stage durations. That combination determines whether the limiter is starving VUs during ramp-up, which would look like a scheduler bug but is actually expected back-pressure behavior.