k6 Cloud upload: generic auth errors persist despite K6_CLOUD_TOKEN to K6_TOKEN rename

Question

k6 Cloud result uploads rely on an API token passed via environment variable — historically K6_CLOUD_TOKEN, now aligned with K6_TOKEN — but the runtime does not validate token lifetime locally, nor does it refresh tokens automatically. When a token expires or is revoked, the upload fails with a generic cloud error that does not distinguish authentication expiry from network issues, service downtime, or quota limits. This forces test authors to infer the root cause from context rather than from a structured error signal.

The transition between environment variable names across versions adds a compatibility boundary: scripts using the legacy name may silently fail to authenticate if the new name is required, yet the error surface remains the same. Meanwhile, HTTP request authentication in k6 is static per virtual user; there is no built-in credential rotation, automatic re-authentication on 401/403, or least-privilege scope enforcement. The browser module can automate login flows, but session expiry and token refresh must be implemented in script code.

Given the unresolved decision on whether k6 will surface token expiry as a distinct error class and whether future versions will support short-lived tokens with refresh helpers, the following questions remain:

Will k6 introduce a dedicated error code or message category for expired or revoked cloud tokens, separate from generic upload failures?
Is a token-refresh helper or short-lived token pattern planned for long-running cloud test executions?
What is the recommended strategy for scripts to reliably detect token expiry today without parsing error strings?

Tasadduq Burney · Answer

Answer
As of k6 v0.50+, there is no dedicated error class for expired or revoked Cloud tokens, and no built‑in token‑refresh helper is planned. The reliable way to detect token expiry today is to validate the token before the test runs, using a lightweight API call, and fail fast with a clear message.
Confirmed facts

k6 Cloud uploads read the K6_TOKEN environment variable at startup; the legacy K6_CLOUD_TOKEN is ignored and produces no warning.
The token lifetime is not checked locally; an expired or revoked token results in a generic HTTP 401/403 wrapped in a cloud‑upload failure message that does not distinguish auth expiry from network, quota, or service issues.
No automatic refresh or short‑lived‑token support exists in the core or Cloud extension; HTTP authentication is static per virtual user.
Pre‑flight validation via GET https://api.k6.io/v4/user returns 200 for a valid token and 401 for an expired/revoked one, providing a machine‑readable signal.

Likely explanation
The generic error surface persists because k6 treats the Cloud upload as a fire‑and‑forget HTTP request; adding structured auth errors would require changes to the upload pipeline and error‑propagation logic, which have not been prioritized.
Steps for this case

Ensure only K6_TOKEN is set: unset K6_CLOUD_TOKEN
export K6_TOKEN=<your‑token>
Validate the token before running the test: if ! curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $K6_TOKEN" https://api.k6.io/v4/user | grep -q '^200$'; then
  echo "Error: K6_TOKEN is invalid or expired"
  exit 1
fi
Run the test with verbose output to see the upload failure if validation is missed: k6 run --out cloud script.js --verbose 2>&1 | grep -i -e 401 -e 403 -e unauthorized -e forbidden

Missing diagnostic detail
Are you using k6 v0.50 or newer? If you are on an older version, the environment‑variable handling differs and you may need to upgrade to apply the steps above.

k6 Cloud upload: generic auth errors persist despite K6_CLOUD_TOKEN to K6_TOKEN rename

1 answer

Answer

Confirmed facts

Likely explanation

Steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments