Skip to main content

Chaos Mode

Chaos Mode is an opt-in checkbox on the New Playtest form. A normal run does exactly what its steps say and nothing more: a clean, well-behaved simulation of a careful user. Real users aren't careful. They double-click buttons that only needed one click, mash the back button mid-form, navigate away before a save finishes, and load your app over a hotel wifi connection that keeps stalling. Chaos Mode's job is to simulate that layer of impatience and poor conditions alongside your scripted steps, to surface the category of bug that a clean scripted run structurally can never hit: race conditions, missing debounce/loading-state handling, and pages that assume a stable, fast connection.

What it actually injects​

Three kinds of noise, layered on top of your normal step execution:

  1. Throttled network. For the entire duration of the run, the browser's network connection is artificially throttled, simulating a slow, inconsistent connection rather than the fast, stable one your test environment normally has.
  2. "Angry" click bursts. After every successful click step, an extra burst of rapid repeated clicks is fired at the same element the step just clicked, simulating an impatient user mashing a button that didn't respond instantly. This runs on a best-effort basis: if it errors out (for instance, because the first click already navigated away and the element no longer exists), that failure is swallowed and doesn't fail the step. The scripted click already succeeded, which is what's actually being graded.
  3. Erratic navigation. After every successful type step, an extra burst of erratic back/forward browser navigation is injected, simulating a user who taps back mid-form-fill, then forward again. Same best-effort handling as the click bursts: its own failure never fails the step.

The philosophy behind both noise injectors failing silently is deliberate. If the chaos noise breaks something (leaves the page in a broken state, for instance), the very next scripted step will fail naturally against that broken page, and that natural failure is the real, reportable finding you want to see in the report. The chaos injection itself is never the thing that's "supposed" to succeed or fail; it's a stress applied to see whether your actual scripted flow still holds up around it.

Cost​

Chaos Mode runs cost 3 credits instead of 1 (see Billing & Credits), reflecting the meaningfully higher execution time and resource use from the extra actions and the throttled connection extending every step's duration.

Timeouts​

Because chaos-mode steps take measurably longer (throttled network alone slows every page load and asset fetch), each step gets a longer execution timeout in Chaos Mode than a normal run's steps do, specifically so that the throttling itself doesn't cause spurious step failures unrelated to a real bug.

When to use it​

Reach for Chaos Mode when:

  • You want to stress-test a flow you already believe works cleanly, to see if it holds up under worse conditions.
  • You're specifically hunting for race conditions: a save button that can be double-submitted, a form that loses data on rapid navigation, a page that breaks if a slow asset hasn't finished loading yet.
  • You're validating loading/disabled states. A well-built button that disables itself the instant it's clicked should be immune to the angry-click burst; one that doesn't will visibly show the effects of being clicked multiple times (duplicate submissions, for instance).

It's not the right default for every run. A first pass at a brand-new flow, or a quick post-deploy sanity check where you just want a fast, clean signal, is better served by a normal run without Chaos Mode.