Inspect error response bodies

A status code tells you something failed. The response body tells you what. Maxoperf captures error response bodies during a run and shows them on the run detail page so you can debug from real data instead of guessing.

When this helps

• A 4xx burst that looks like an auth issue but might be a validation error.
• A 5xx that lists a specific upstream service in the body.
• A test scenario that produces unexpected redirects or HTML error pages.

How to read error bodies

1. Open the run and switch to the Errors tab.

   

   Run detail Errors tab — the summary bar shows total and distinct error counts before you drill into a row.

2. Filter by status code or by request label to narrow down the slice you care about.

3. Click a row to open the error detail panel. The captured response body appears, along with the request method, URL, and the timestamp of the failing sample.

4. Look at the body content. Most APIs return structured JSON with a clear error code or message — that is usually the fastest path to the root cause.

5. Cross-reference with logs. The Logs tab shows what the runner did around the same timestamp; together with the response body you usually have enough to act.

What is captured and what is not

• The response body is captured for failed requests (non-2xx status codes and assertion failures).
• A configurable cap on body size keeps the captured payload reasonable. Very large bodies are truncated with a marker.
• Request headers and bodies you sent are not captured by default to avoid leaking secrets. The exact request shape is in the test files you uploaded.

Sensitive responses

If your target returns sensitive data in error responses (account numbers, PII, internal IDs), be careful about who can view the run. Project-level access controls determine who can see captured response bodies.

When the body alone is not enough

If the captured body is empty or unhelpful (for example, an HTML error page that does not name the cause), the next step is usually:

• Reproduce the same request manually against the target and compare responses.
• Check whether the test data variant is missing a required field — see Data entities, parameters, and variants.
• Confirm secrets are bound correctly — see Manage test secrets.

Where to go next

• Read run results and logs — full reading order for a finished run.
• Run stuck or failed — diagnose run-level failures.
• Build reporting dashboards — pin an error-rate chart so you spot regressions early.