Reports

Understand the output formats generated by Overload.

Run Folder Layout

Every run writes its output to its own isolated folder under reports/:

reports/
  run_20260609_153021_abc123/
    report.html        ← HTML report (charts, stats, request log)
    meta.json          ← Run metadata sidecar (persists history across restarts)
    responses.json     ← Response bodies (only present when --save-responses is used)

The folder name embeds the datetime and a short random suffix so it is both human-readable and collision-proof. On restart, Overload scans reports/run_*/meta.json to restore past runs in the Results table automatically.

HTML Report (Default)

The HTML report is a self-contained, single-file document — embeds all CSS and JavaScript so you can share it by email or Slack without worrying about missing assets.

Contents:

• KPI Summary: Total requests, success/error rates, avg/P95 latency, duration, avg RPS.
• Verdict Banner: PASS/FAIL with a per-assertion breakdown (only when --assert flags were used).
• Status Codes Doughnut: Visual breakdown of HTTP response codes.
• RPS Stacked Bar Chart: Traffic over time, stacked by outcome (2xx, 4xx, 5xx, network errors).
• Latency Timeline: Scatter plot of every request's latency over the test duration.
• Latency Histogram: Distribution of response times across fixed buckets.
• Request Log: Filterable table of requests — method, URL, status, latency, errors. First 500 rows shown.

Generate it explicitly:

overload run --collection api.json --format html

Saving Response Bodies

By default, response bodies are not saved to keep tests memory-efficient. Enable it to capture the first 10 KB of each response for debugging:

# CLI
overload run --collection api.json --save-responses

# Browser UI
# Toggle the "Save response bodies" checkbox on the Runner page before starting.

When enabled, a responses.json file is written alongside report.html in the run folder. It contains every captured body with its matching URL, status, latency, and timestamp. The HTML report itself does not embed the bodies (keeping it lean and shareable).

In the browser UI, the Results table shows a Responses download button next to the HTML Report link whenever bodies were captured. The API endpoint is:

GET /api/runs/{run_id}/responses

responses.json schema:

{
  "run_id": "20260609_153021_abc123",
  "count": 42,
  "responses": [
    {
      "index": 0,
      "request_name": "Create User",
      "method": "POST",
      "url": "https://api.example.com/users",
      "status": 201,
      "latency_ms": 87.4,
      "timestamp": 0.0,
      "response_body": "{\"id\":\"u_123\",\"email\":\"alice@example.com\"}"
    }
  ]
}

Partial Reports on Stop

Stopping a test — whether by clicking Stop in the UI or sending Ctrl+C in the CLI — always produces a partial report from the data collected so far. Nothing is discarded.

• The run status is recorded as stopped (distinct from complete).
• The Results table shows the HTML Report link for stopped runs, just like completed ones.
• A meta.json sidecar is written so the partial run appears on restart too.

JSON Export

To feed results into a custom dashboard or analytics pipeline:

overload run --collection api.json --format json

Also available per-run from the browser API: GET /api/runs/{id}/export/json

CSV Export

One row per HTTP request — raw, unaggregated timeline data.

Columns: timestamp, request_name, method, url, status_code, latency_ms, error, body_size_bytes

overload run --collection api.json --format csv

Also available per-run: GET /api/runs/{id}/export/csv

JUnit XML

Translates assertion results into a standard format recognised by GitHub Actions, GitLab CI, Jenkins, and Azure DevOps.

overload run --collection api.json --assert "p95_latency_ms<500" --junit results.xml

Run History

The browser UI and GET /api/runs automatically load historical runs on startup by scanning the reports/ directory for meta.json sidecars. This means you can close and reopen Overload without losing your run history, as long as the reports folder is preserved.