Quick answer: An HTML scenario report is a self-contained record of the run, showing each ordered step, the assertions evaluated, and the raw responses, with known credential fields redacted and large payloads folded. Read the failed step first to see the check that broke, then trace the extracted variables back to their source. The report exports in ten built-in languages and can be shared without the running app.
What the report contains
Because the report is self-contained, it carries the evidence from the run rather than a link back into the desktop. It is built to be read by someone who was not watching the live execution.
- The ordered steps in the sequence they ran.
- The assertions evaluated at each step and their results.
- The raw responses, including status, headers, and body.
- The extracted variables passed between steps.
This gives a reviewer the same trail the live run produced, so a failure can be diagnosed from the report alone.
The report is also the right artifact to attach to a bug or a handoff, because it pins the exact responses behind the failure. A reviewer can rerun the same steps without reconstructing the setup, and the folded payloads keep the attachment small enough to read inside a ticket rather than a separate archive.
How the report stays safe to share
Two built-in protections matter when the report leaves your machine. Known credential fields are redacted automatically, so secrets in the captured traffic do not get handed around, and large payloads are folded so the document stays readable instead of dumping a wall of data.
| Element | How it appears |
|---|---|
| Steps | Ordered, with the request each one sent |
| Assertions | Each check and whether it held |
| Raw responses | Status, headers, and body for the step |
| Credentials | Known fields redacted automatically |
| Large payloads | Folded to keep the report compact |
A practical reading order
Start from the failure rather than reading the whole run top to bottom.
- Find the step marked failed and read the assertion that did not hold.
- Open the raw response at that step to see the status and body.
- Check the variables the step received from earlier requests.
- Trace a bad variable back to the step that produced it.
- Confirm whether the failure was a hard fail or an inconclusive result.
A 200 at the failed step is not a contradiction. The response can carry a green status while a field assertion fails or the body breaks the contract, and the report shows both the status and the failed check rather than collapsing them. An inconclusive result means verified evidence was missing, not that the step passed.
Honest limits
The report records only the run that produced it, covering the steps and assertions defined for that scenario. It is not a live view and does not update after export, so a later rerun means a new report. Redaction covers known credential fields, but you should still review what you share, since static handling cannot guarantee every possible secret is recognized.
Scenarios run against real connected requests and stay outside the OpenAPI document with no x-scenarios keys. The report is evidence of that run, not a substitute for the next one.
Powerduck exports the HTML report with the per-step evidence, redaction, and folding built in, so the failure and its context travel together.
Frequently asked questions
Does the report need the app to open? No. It is self-contained HTML and can be shared and read on its own, in one of ten built-in languages.
Are credentials removed from the report? Known credential fields are redacted automatically, and large payloads are folded. Still review the report before sharing, since not every secret can be guaranteed recognized.
Where do I look first when a step failed? Read the failed assertion and the raw response at that step, then trace the extracted variables back to the earlier step that produced a bad value.
The bottom line
An HTML scenario report is a shareable, self-contained trail of the run: ordered steps, per-step assertions, raw responses, and the variables passed between them, with credentials redacted and large payloads folded. Start from the failed check, inspect the response, and trace the inputs back rather than reading the whole run. Treat it as a record of one execution rather than a live view, and remember that a 200 can sit beside a failed field assertion. Continue in the API scenario testing guide.
