Runs — read results

1. 0:02 Is it passing?
2. 0:47 Where is it slow?
3. 1:40 Why is it failing?
4. 2:03 Is the load generator the bottleneck?
5. 2:59 Did it get worse?
6. 3:27 Dig into raw data
7. 3:55 Share it

Investigate run results.

What this is

The Runs surface is where you find and read every load-test execution in the workspace. A run is a single execution of a test definition. It captures real-time metrics while active and immutable results when complete. Each run has eight tabs: live charts, per-request metrics, grouped errors with captured request and response samples, SLA criteria verdicts, runner-level health, an immutable configuration snapshot, raw logs, and downloadable artifacts.

Where to find it

Select Runs in the left navigation sidebar. The page lists all runs in the active workspace. Click Open on any row to go to that run’s detail page.

---

Run lifecycle

Every run moves through the same lifecycle. The console shows the status as a badge, and the API returns it too.

Status	Meaning
queued	The run is accepted and waiting for capacity to be assigned.
allocating	MaxoPerf is reserving the runners needed to generate load.
starting	Runners are spinning up and preparing to execute.
running	The test is generating load and producing results.
stopping	A cancel or natural end has been requested; runners are draining.
finished	The run completed; results are final.
failed	The run could not complete successfully. The Overview tab’s failure callout explains why.
cancelled	A user cancelled the run before it finished.

A run usually reaches running within seconds. If a run stays in queued or allocating for longer than expected, see Runners not allocating.

Runs are immutable. When a run finishes, MaxoPerf keeps its result data (latency percentiles, throughput, errors, logs, and runner health) as the record of what happened. If you change the test and re-run, the new run captures the new definition, and the previous run keeps its own configuration snapshot (see Run detail: Configuration below).

---

Runs list

The Runs list shows execution history for the active workspace as a paginated table. Columns are Run (name), Test (test name + id), Location (cloud provider and region), Engine, Status (badge with optional failure reason), Started (timestamp in your local timezone), and an Open action link.

Runs list: paginated execution history for the active workspace. Use filters to find runs by status, time range, test, location, or engine.

Filters

Six filter controls appear above the table:

Filter	What it narrows
Search	Run name, id, or test name (substring)
Status	All statuses · Queued · Running · Passed · Failed · Cancelled
Location	All locations · BYOC
Test	All tests or a specific test definition in the workspace
Engine	All engines or a specific Taurus executor
Date range	From / To datetime picker. Narrows by run start time

How to use the Runs list

1. Select a workspace in the scope switcher in the top bar. The list is blank without one.
2. Use Status to find all failed runs in the workspace.
3. Use the date range picker to limit the list to a time window (e.g. yesterday’s load-test window).
4. Use Test to see all runs of a specific test definition.
5. Click Open on any row to go to that run’s full detail page.

Failure reason in the list

When a run failed or was cancelled with a known reason, a short, truncated failure reason appears below the status badge. Hover the row to see the full message, or open the run and read the failure callout on the Overview tab.

---

Run detail: Overview

The Overview tab opens first when you open a run. It summarises the run’s key performance indicators, health trends, and status, live or after completion.

Run detail, Overview tab: real-time KPI cards, throughput and virtual-user charts, latency distribution, and runner health trend. Refreshes automatically while the run is active.

The Overview tab contains:

Run header: status badge (Queued, Running, Passed, Failed, Cancelled), linked test name, and the load engine. While a run is active, it shows a Cancel button; after completion, a Re-run button.

Failure callout: if the run failed, a callout explains the failure reason. It may include a link to the Criteria tab if a criterion was breached.

Blocked traffic notice: if most of the run’s failed requests were 403 or 429 responses (or the target’s WAF identified itself in the responses), a warning explains that your target may be blocking MaxoPerf traffic. It shows the blocked share and the response codes, and lists how to fix it: allowlist the runner IPs in your WAF or CDN, ask the WAF to bypass requests that carry a custom header you add to the test, or lower the request rate or ramp up more slowly. It appears only when blocking is detected on a finished run, with enough traffic to be meaningful. The same verdict is available as GET /v1/runs/{runId}/dashboard/blocked-traffic and as the blockedTraffic field of the run’s executive summary (also returned by the get_run_summary MCP tool).

Failure summary (browser experience tests): when a run with a browser probe fails, one summary on the Overview says which part failed (the load, the browser probe, or both) and why, instead of repeating the same failure in several places. The video tile on the Overview keeps the recording’s own aspect ratio and starts at the moment the load began, so you see the page as the load hit it.

Runtime secret injection panel: if secrets were bound to the test, this panel lists the env-var names injected at run start (never the values).

Charts: three charts in a row: Latency overview (p-percentile distribution bars), Throughput (requests/second over time), and Virtual users (active VU count over time). The throughput and VU charts update live while the run is active, following the live tail. Error lines are always red.

Metric cards: seven KPI cards across the bottom:

Card	What it shows
Alive runners	Runners alive in the last 60 seconds (fraction of total)
Error rate	Percentage of requests that errored in the selected timeframe
Bandwidth	Network receive (↓) and transmit (↑) in MiB/s
Average response	Mean response time across aggregate samples
Ingestion delay	Average event_time → ingested_at delay across last samples
Max CPU trend	Peak runner CPU percentage in the selected window
Samples	Total Taurus aggregate samples (plus error count if non-zero)

Runner health trend: a chart of CPU, memory, and network across all matching runners for the selected timeframe, with max and average lines per metric.

How to use the Overview tab

1. Open a run from the Runs list.
2. Read the status badge and failure callout for the pass/fail result.
3. Watch the Throughput and Virtual users charts to check that the ramp-up reached the target and held steady.
4. Check Error rate. A non-zero value turns the card red.
5. If the run is live, the charts follow the live tail. Use the timeframe range slider (on the Metrics tab) to zoom in on a window.
6. Click Re-run (after completion) to launch a new run from the same test definition.

Live tail overlap

During active runs, the Overview charts apply a small live-tail overlap, based on the observed ingestion delay, so the chart’s right edge has no gaps. The ingestion-delay metric card shows this delay.

---

Run detail: Metrics

The Metrics tab is an interactive metrics explorer for this run.

Run detail, Metrics tab: the metrics dashboard builder. Select a dashboard, add chart panels, and filter by location, label, or runner.

Key controls on the Metrics tab:

• Dashboard selector: switch between saved dashboards or create a new one.
• Timeframe range slider: drag the handles to narrow the chart time window. A Reset button returns to the full run span. An Undo button steps back one zoom level.
• Scope filters: filter every chart at once by Location, Label (request label / transaction group), Runner, and Scenario (for VarioTests).
• Chart panels: each panel can display a different metric series. Use the panel controls to pick the metric, change chart type, and set the aggregation.

How the Label filter counts. COMBINED means all labels together, and it’s what you see when no label is selected. Pick one or more labels to see exactly those labels. COMBINED and individual labels can’t be selected at the same time, because every request would then be counted twice. Picking a label clears COMBINED, and picking COMBINED clears the labels. An older shared link that mixes the two opens with just the labels and a short notice. With labels selected, the Virtual users chart and Max VUs achieved show the users of the scenarios running those labels. A test with one scenario runs every label with all its users, so the number matches the whole run. Labels are never counted twice.

Aggregations that add up runners. For virtual users and threads the aggregation list is SUM (the default), MAX, MIN and P95, and every option is already a total across runners: SUM adds up each runner’s average level in the time bucket, MAX adds up each runner’s peak, and so on. SUM is also available for runner container memory (current, working set, swap) and disk I/O, where it adds the runners together. Percentages, latencies and node-wide host metrics never offer SUM, because adding them would double count.

Metric series names follow the naming conventions of the run’s load engine (k6, JMeter, Taurus). See Executors for metric name mappings.

How to use the Metrics tab

1. Open the Metrics tab on any completed or live run.
2. Use the timeframe range slider to zoom into the period you care about (e.g. when error rate spiked).
3. Select a scope filter to isolate data for one location or request label.
4. Click Add panel to add a new chart, then pick the metric from the selector.
5. Save the arrangement as a dashboard to reuse across future runs.

For a full step-by-step guide, see Build reporting dashboards.

---

Run detail: Criteria

If the test had failure criteria at run time, the Criteria tab shows the evaluation status of each one.

Run detail, Criteria tab: traffic-light verdict for each SLA gate defined on the test. Breached criteria show the observed value, threshold, and breach timestamp.

Each criterion row shows:

Field	What it shows
Status badge	ok (green), breached (red), pending (grey), or skipped (muted)
Summary	Human-readable description of the criterion
Observed value	The actual measured value at evaluation time
Threshold	The configured SLA limit
Window	The evaluation window (e.g. “last 30 seconds”)
Stop source	The runner that triggered an early stop, if applicable
Breached at	The timestamp when the criterion was first breached

Criteria tab visibility

The Criteria tab is only visible when the test had at least one failure criterion defined at the time the run was created. If you don’t see the tab, no criteria were configured. Add them on the test’s Configuration tab.

How to read criteria results

1. Open the Criteria tab after a run completes.
2. A breached row means the run failed the SLA gate for that criterion. Compare the observed value with the threshold.
3. A pending row means the criterion was not evaluated (typically because the run did not reach the evaluation window).
4. A skipped row means evaluation was skipped (e.g. not enough data for the configured window).

---

Run detail: Runner status

The Runner status tab lists every runner allocated for this run.

Run detail, Runner status tab: per-runner lifecycle view. Filter by status, engine, or location. Pin runners to scope charts on the Overview and Metrics tabs.

Each runner row shows:

• Status badge (Booting, Starting, Running, Stopped, Failed)
• Location: cloud provider and region, or private datacenter name
• Engine: the load engine that ran on this runner
• Exit code: the process exit code on termination
• Lifecycle timestamps: when the runner started and stopped
• Health drawer: expand to see CPU, memory, and network trends for this runner only

Filter controls narrow the list by runner status, engine, or location. You can also pin runners. Pinned runners become the scope filter on the Overview and Metrics tabs, so you can isolate charts for a single runner.

How to use the Runner status tab

1. Open the Runner status tab.
2. Use the status filter to find any runners that failed during the run.
3. Check the exit code of failed runners. A non-zero code means the runner process crashed or the engine reported an error.
4. Click a runner row to expand the health drawer and inspect CPU and memory for that runner.
5. Pin a runner to scope the Overview charts to that runner’s traffic.

---

Run detail: Configuration

The Configuration tab shows the immutable test configuration snapshot captured when this run was created.

Run detail, Configuration tab: the exact test definition this run used, frozen at creation time. Use it to audit what ran.

The snapshot is read-only and has these sections:

Configuration snapshot: test name and id, project, workspace, detected engine, private datacenter (or “Managed cloud”), and the capture timestamp.

Validation: the engine validator result (pass / fail / pending) at snapshot capture time, including the reason text if validation failed.

Load profile: the exact virtual-user target, runner count, ramp-up, stop mode (duration or iterations), max VUs per runner, and target RPS that were used for this run.

Location plan: the managed regions and private datacenter ids used, plus a per-row table of runner counts and weights.

Files: the list of test files (filename, role, content type, size, SHA-256 checksum) captured at run time. Each row has a Download button to retrieve the original file.

Legacy runs without a snapshot

Runs created before MaxoPerf introduced immutable snapshots show a “Snapshot unavailable” empty state. An Open current test configuration link takes you to the live (editable) configuration on the test page.

How to use the Configuration tab

1. Open the Configuration tab to audit which files, load settings, and locations the run used.
2. Compare Load profile values across multiple runs of the same test to confirm consistency.
3. Click Download on a file row to retrieve a copy of the exact script that ran.

---

Run detail: Errors

The Errors tab sits right after Request stats, so the tab you open after reading latency is the one that explains failures. Its label carries the run’s error count, for example Errors (1.2K); the label is plain Errors when the count is zero or not yet known. The tab groups failed requests into rows, each with captured request and response samples for the engines that expose them.

Run detail, Errors tab.

The tab has two views: By error type groups rows by category (Server errors (5xx), Client errors (4xx), Timeouts & network, Assertion failures, Other errors) and normalized signature; By transaction groups the same errors by request label. Each row shows the category, the signature, the count, the percentage of requests it accounts for, a trend sparkline, and when it was first and last seen. Selecting a row opens a detail pane with First, Last, and Recent sample tabs, each showing the captured request and response.

How to use the Errors tab

1. Open the Errors tab after a run completes or while it is running.
2. Choose By error type to see which kinds of failure dominate, or By transaction to see which requests fail.
3. Select a row to open its detail pane.
4. Open the First, Last, or Recent sample to read the captured request and response.
5. Switch to the Metrics tab to see the error-rate trend as a chart.

Scoped by global filters

The error rows respect the location, label, runner, and scenario scope filters set on the Metrics tab. While the Transactions filter is set to anything other than All transactions, the detail pane shows no samples, because samples aren’t linked in filtered views.

For more on reading captured error bodies, see Inspect error response bodies.

---

Run detail: Logs

The Logs tab streams log output from all runners and the platform during the run.

Run detail, Logs tab: a terminal-style viewer over engine and system output. Filter by stream, severity and runner, find text with next/previous, wrap long lines, follow live output, and download the loaded lines.

One toolbar sits above the log:

Control	What it does
Stream	All · System (platform-api log lines) · Engine (runner log lines)
Severity	All · Info · Warn · Error
Find	Narrows to lines containing the text and highlights every match. Press Enter / Shift+Enter (or the arrows) to jump between matches; the counter shows match / total.
Runners	Limits the log to selected runners. This runner scope applies to every tab of the run.
Wrap	Wraps long lines, or keeps each on one line with horizontal scrolling.
Follow	Shown while the run is live. Keeps the newest lines in view at the top; scrolling down pauses it, click it again to resume.
Download	Saves the lines loaded so far, with the current filters applied, as run-<id>-logs.log.

Newest lines are at the top. Each line shows timestamp (UTC), severity, stream and source (runner id or platform-api), and the message. Hover a line to copy it. Older lines load as you scroll down.

How to use the Logs tab

1. Open the Logs tab during or after a run.
2. Select Engine to see only the load-engine output (Taurus / JMeter / k6 stdout), or System for platform events (runner provisioning, secret injection, finalize).
3. Select Error severity to see only error-level lines.
4. Type in Find to narrow to a URL, label or error message, then step through the highlighted matches.
5. Scroll down to load older lines. Click Download to keep a copy of what you loaded.

Log retention

MaxoPerf keeps logs for a limited period. For long-term audit trails, download the log artifact from the Artifacts tab before retention expires.

---

Run detail: Artifacts

The Artifacts tab lists every output file runners generated during the run: JMeter JTL files, k6 JSON summaries, custom engine output, and platform-level archives.

Run detail, Artifacts tab: every output file in one table with a Runner column. Switch to By runner to group them. Status badges show ready, uploading (live), failed, or discarded.

All files appear in one table with a Runner column (platform-generated files, e.g. compressed log archives, show as Run-level). A summary line above the table shows the file count, total size and count per type. Switch the layout to By runner to see one table per runner instead; the console remembers your choice. Engine output files such as JMeter’s error.jtl contain raw requests and responses and are not redacted, unlike the samples on the Errors tab.

Table columns:

Column	What it shows
File	File-type icon and filename (truncated with tooltip)
Runner	The runner that produced the file, or Run-level
Source	The runner or engine instance that produced the file
Status	Ready (downloadable), Live (uploading with committed bytes), Finalizing, Failed, or Discarded
Size	File size in bytes / KiB / MiB / GiB
Updated	Last updated timestamp
Download	Download button (enabled when status is Ready or Live)

Filters above the table narrow it by search (filename), type (Log, Report, Data or Other, each chip showing its count), and source.

How to download artifacts

1. Open the Artifacts tab after a run.
2. Find the file you want. Use the search box, the type chips (Log, Report, Data, Other) or the source filter to narrow the table.
3. Click Download on any row with status Ready or Live.
4. To download several files at once, check the rows you want and click Download selected. The browser builds a ZIP archive.

Live artifacts

While a run is active, artifacts in “uploading” status with committed bytes show as Live, and you can download them already. You do not need to wait for the run to finish to get a partial JTL or log file.

Batch download limit

Only artifacts with Ready or Live status can be batch-downloaded. Items that are not ready block a batch download, so deselect them first.

---

Tips & gotchas

• Live vs. completed runs. While a run is active, the Overview and Metrics charts follow the live tail. Filters and timeframe controls still work during live runs. When the run completes, all data is frozen and the timeframe defaults to the full run span.
• Criteria tab only appears when criteria exist. If the test had no failure criteria at run time, the Criteria tab is hidden. Add criteria on the test’s Configuration tab for future runs.
• Runner status tab is blank for older runs. The Runner status tab needs runner telemetry. Very short runs, or runs at a very early stage, may show no runner rows.
• Error counts vs. error rate. The Errors tab shows raw error samples (individual request failures). The error rate (percentage) is on the Overview metric card and Metrics tab charts. A high error sample count can still mean a low error rate when overall volume is high.
• Configuration snapshot vs. current configuration. The Configuration tab shows what ran: the immutable snapshot. The live, editable configuration is on the test’s Configuration tab. The two differ if someone changed the test after this run was created.
• Artifact status “Discarded”. Discarded artifacts were deliberately not kept (e.g. the runner shut down before the file was fully committed). Check the failure reason in the status tooltip.
• Cancelling a run. The run header offers two cancel modes: Graceful (runners drain final data and release capacity) and Kill (capacity is removed immediately; final samples may be incomplete). Use Graceful unless you need to stop immediately.

---

Related docs

• Executors: engine-specific metric names and artifact formats.
• Read run results: a task-oriented walkthrough of reading a completed run.
• Run your first test: end-to-end walkthrough from test creation to reading results.
• Build reporting dashboards: save and share Metrics dashboard layouts.
• Inspect error response bodies: debug specific HTTP errors from run data.
• Tests — create and configure: create the test definition that generates runs.
• Navigating the console: shell, Dashboard, and navigation reference.