k6 Cloud test investigator

Structured 9-step workflow for investigating a Grafana Cloud k6 test or run.

This skill is workflow-only. All API calls go through gcx api against the plugin proxy, using v6 for REST and v5 for metrics. For the underlying mechanics (gcx auth, path conventions, endpoint discovery, log queries, script editing, threshold semantics, gotchas), see the k6-manage skill — every step below references it.

The content unique to this skill is:

• the ordered investigation flow (Steps 1-9 below)
• the date-alignment check ("last 7 days" ≠ "last 7 runs")
• the 3-layer pass/fail determination (result vs status vs per-check checks query)
• a worked example with realistic numbers (references/worked-example.md)

Core principles

1. Read before write. Always GET the script before any PUT. gcx k6 load-tests update-script is a write that replaces the live script with whatever file you pass — running it "just to see the URL it hits" has cost users their production scripts. If you need to learn URLs, run any non-mutating command with -vvv --log-http-payload instead.
2. Paginate when enumerating runs. The /test_runs endpoint caps at 1000 rows and gcx k6 runs list --limit 0 does not auto-follow @nextLink. Use the gcx api loop documented in k6-manage §3.
3. Verify date framing. When the user says "last 7 days", "this week", "recent runs" — confirm the most-recent run's created actually falls in that window. Surface the gap if not.
4. check() doesn't fail runs; only thresholds do. And thresholds with zero observations are reported as ✓ pass. See "Threshold semantics" below for the full deep dive; the per-check checks metric query in Step 5 catches both cases.