Load Runner

Stress-test any request with bounded concurrency. The Load Runner sends the same request N times, controls how many are in-flight at once, and surfaces live performance metrics as it runs.

Configuration

Total requests — how many times to send the request in total.
Concurrency — how many requests can be in-flight simultaneously.
Per-iteration delay (optional) — milliseconds to wait between dispatching each request.

Each iteration re-resolves {{random}}, {{timestamp}}, and all other dynamic variables, so every request in the run is unique.

Live Metrics

While a run is in progress the metrics panel updates in real time:

Sent count, remaining count, and requests per second (RPS)
Latency percentiles: p50, p95, p99
Overall success rate (percentage)
Status code histogram — e.g. 200, 201, 400, 500, and any other codes encountered
Error kind breakdown — timeout, connection refused, TLS error, etc.

Response Validator

Optionally configure pass/fail criteria before starting a run:

Expected status codes — a comma-separated list such as 200, 201. Any response outside this set is flagged as a validation failure.
Body contains — an optional substring that must appear in the response body. Requests where the body does not contain this string are flagged.

Validation failures appear in the console log as yellow rows, distinct from network errors (red) and successes (green).

Controls

Start — begins the run with the configured parameters.
Stop — halts the run mid-way. Partial results and metrics collected so far are preserved and remain visible.

The console log at the bottom of the panel shows one row per completed request, color-coded:

Green — request succeeded and passed validation.
Yellow — request completed but failed the response validator check.
Red — network-level error (timeout, refused, TLS failure, etc.).

Tab isolation

Load test state — config, run id, progress snapshot, event log — lives on the tab in the application state. A run started in tab A continues when you switch to tab B; coming back to tab A shows the live progress. Closing a tab aborts its running load run.

Number input editing

The Total requests, Concurrency, and Per-iteration delay fields accept free-form editing. Clear the entire value and type a new number without the field snapping back to 1 mid-edit. Values clamp (minimum 1 for counts, 0 for delay) when you leave the field or press Start.

Event log scroll

The event log has a fixed-height scroll area so the metrics row above it stays visible. Auto-scroll is on by default. Scrolling up manually pauses it. Click Auto-scroll to resume anchoring to the bottom.

Watched response headers

Track up to 10 response headers across all iterations and see per-header statistics after the run.

Workspace-level config — open Collection Settings, go to the Load test tab. Add header names to the watched list and toggle Auto-track Scrape.do-* headers (on by default). Saved to .scrapeman/collection.yaml.
Per-run override — the Load Test panel has a Watched headers chip input above the config form. Anything added there replaces the workspace list for that run only.
Click-to-add from a response — hover any row in the response Headers tab. A + icon appears on the right; click it to append that header to the workspace watched list.

After the first tick with stats, a Watched headers section appears below the metrics grid. Each card shows the header name, total times seen, percentage of total iterations, status pills (All, 200, 429, …), the top 5 unique values as a bar chart, and numeric stats (min / max / avg / p50 / p95 / p99) when at least 95% of seen values parse as numbers and at least 5 values have been collected.

Save failed responses

Enable Save failed responses in the config form before starting a run. The runner captures the response body of every failed iteration (validation failures and network errors). Bodies are truncated to 64 KB before being stored in memory.

The Limit field caps how many bodies are kept (1 to 1000, default 50). When the limit is reached, older entries drop as new failures arrive.

After the run, a Failures panel appears below the event log. Each row shows iteration number, status code, duration, and a brief reason; click to expand and view the raw body (JSON is pretty-printed). Export JSON saves all captured failures to a file. The ring buffer is in-memory only; failures do not persist across app restarts.

Run-parameters pills

While a run is live, the metrics block shows total · concurrency · delay · status · body ⊃ "..." pills so you can confirm what is actually being executed at a glance.