k6 from a phone (retired 2026-09-05)

Update 2026-09-07. API stress (k6) was retired on 2026-09-05: no new runs on any plan, and k6 share links are gone. Everything below documents one dated run from 2026-08-10 — it is a historical record, not a reproducible workflow.

A k6 script can be written on a laptop. The interesting question back then was what happens when you fire it from your phone while standing in a coffee shop, in a customer call, or away from your terminal. This post documents one dated run of that retired workflow on the Well Tested mobile shell, the exact parameters we used, the steps we took, and the limits of what a single trial can tell you.

This is not a benchmark against other tools. It was one reproducible walkthrough with the measured parameters at the time; you can no longer copy the workflow on Well Tested because k6 execution is retired.

Methodology

Date of run: 2026-08-10 (UTC). Author: Serdar Celebi, Founder of Well Tested. Tool under test: Well Tested mobile shell at /app/vibe on a paid workspace. Execution plane: Well Tested's k6 worker (workers/k6); the phone is the remote, not the runner. Target: https://welltested.io/check — a public, anonymous URL on our own marketing surface. Choosing our own endpoint keeps the example self-contained and avoids any third-party rate limits. Plan tier used: the mobile-web tier of the plan ladder in use at the time, since retired. Current plans are Builder $29/mo, Team $99/mo and Scale $299/mo; see /pricing. Engine capability surfaced (retired): the k6 worker ran up to 100 rps and 60s duration on that tier (the top tier raised this to 1,000 rps / 600s). Retired 2026-09-05 — no new runs.

What we measured, and what we deliberately did not:

• Measured: the steps it took to fire a run from a phone, the parameters the shell exposed, and the shape of the evidence page that came back.
• Did not measure: absolute latency, percentile distributions, or error rates for your workload. A single run against one endpoint is a smoke test of the workflow, not a benchmark of Well Tested versus Grafana Cloud k6 or any other tool.

If you want a side-by-side benchmark, run the same script through k6 run locally and compare the http_req_duration quantiles against the numbers recorded below yourself. The OSS k6 docs describe the methodology at k6.io/docs. (The mobile-shell half of this comparison no longer exists — k6 execution is retired.)

The walkthrough, in seven measured steps

1. Open /app/vibe on the phone. No install. The mobile shell is a responsive web app — it renders the same workbench as /app on desktop, sized for the viewport. We signed in on a paid workspace.
2. We saved a k6 scenario on the desktop side first (retired workflow). The scenario was the unit of run-from-phone: target URL, target rps, duration. We saved one named check-endpoint-smoke against https://welltested.io/check at 50 rps for 30 seconds.
3. Pick the saved scenario on the phone. The mobile shell lists saved scenarios. Tap check-endpoint-smoke.
4. Hit Run. Status pushes back over the same shell. The execution plane is the server; the phone is the remote.
5. Watch status in the same shell. No separate app, no separate dashboard. Status is rendered inside /app/vibe — current iteration, time elapsed, exit state.
6. Wait for completion. For 50 rps × 30s, the run finished in just over 30 seconds of wall clock plus a short evidence-rendering tail. That tier capped duration at 60s; the top tier raised it to 600s.
7. Open the token-gated public proof page. The shell surfaced a /vibe/k6/<runId>/share?t=<token> URL. The proof page showed request count, throughput, status-code distribution, and the raw k6 worker output. (k6 share links are gone since the 2026-09-05 retirement; pre-cutoff history stays in evidence.)

What the evidence page surfaced

The retired k6 proof page at /vibe/k6/<runId>/share?t=<token> was the canonical artifact. It exposed:

• Request count — total HTTP requests fired by the worker.
• Throughput — average requests per second, computed from request count and duration.
• Status-code distribution — 2xx / 3xx / 4xx / 5xx counts.
• Duration quantiles — p95 and p99 from k6's http_req_duration metric.
• Worker log — the raw k6 stdout for the run.

These five fields are what k6 itself emits; the proof page is a token-gated wrapper around that output. Anyone with the share URL can view; the token gates who gets to see it.

Limitations

A single walkthrough is not a benchmark. We state this explicitly because the audit on 2026-07-24 flagged that we should not market unsupported superlatives or fabricated market statistics. The limits of this post are:

• One target, one rps, one duration. This is a smoke test of the workflow, not a characterization of your service.
• No comparison to other tools. If you want a comparison, run the same scenario with k6 run locally and compare against the numbers recorded here yourself. (The mobile-shell half retired with k6 execution on 2026-09-05.)
• The target is our own endpoint. That avoids third-party rate limits; it does not characterize performance on third-party services.
• One date. Run results change with deploys, traffic, and time of day. The numbers in the proof page are timestamped.
• One author. A single named author (Serdar Celebi, Founder) takes responsibility for the methodology and the run.

What this is for

If you are deciding whether to evaluate the mobile-shell workflow, this post records the exact steps we took on our own endpoint back then. If you are looking for a benchmark against k6 run or Grafana Cloud k6, run your own comparison — this post does not provide one, and we will not fabricate one.

There is no live retired-notice page — the former guide URL now returns a retired-status response. For current plans and credits, see /pricing.

Changelog

• 2026-08-10 — Initial publication. Methodology, walkthrough, evidence-page description, limitations. Author: Serdar Celebi, Founder.