Skip to main content
When a runbook finishes, it doesn’t just tell you the overall result — it produces a structured report that shows exactly what happened at each step. The report is designed to be shared: dropped into a ticket, sent to a team lead, or attached to a case. It gives the reader enough to understand the situation without having to re-run anything.

​
When to use it

The report is automatically generated at the end of every runbook run. It’s most useful when:
  • A support agent needs to escalate a finding with documentation.
  • A team needs a record of a routine operational check.
  • A step failed and someone needs to understand what was tested and what went wrong.
  • You’re closing out a support case and need to attach evidence.

​
Key concepts

Summary section. The top of the report gives the headline: overall pass or fail, the journey and Case used, the environment, who ran it, and when. A quick read tells you whether the run succeeded. Step-by-step results. Below the summary, each step is listed with its outcome — passed, failed, or skipped — and the key details from the evidence log. You don’t have to dig through raw logs; the report surfaces what’s relevant. Failed steps. For any step that failed, the report highlights which assertion didn’t pass, the expected value, the actual value, and the full response. This is the section people usually need when investigating a problem. Manual checkpoint results. Checkpoint outcomes — the pass/fail mark and the user’s note — appear inline with the step they belong to. Human observations sit alongside automated results. Shareable format. Reports are designed to be shared. You can copy, export, or link to a report to attach it to a ticket, a case, or an external tool.

​
How it works

When the last step of the runbook completes (or the run is marked done), Reqflo compiles the evidence log into the report. No extra steps required. From the report view you can:
  • Review the full step-by-step breakdown.
  • Expand individual steps to see request/response details.
  • Copy the report or export it for use in a ticket.
  • Navigate back to the journey to rerun with different values or dig deeper in debug mode.
If a run was abandoned partway through, a partial report is still generated for the steps that completed.

​
Examples

Summary block 
Journey:    Payment initiation flow  (v3)
Case:       Missing funding source
Environment: staging
Run by:     support-agent@example.com
Started:    2026-06-13 14:03 UTC
Completed:  2026-06-13 14:09 UTC

Overall result: FAILED
  2 steps passed
  1 step failed
  1 checkpoint failed
A passing step 
✓  Step 1: Authenticate
   POST /v1/auth/token  →  200 OK
   Assertions: all passed (1/1)
A failing step 
✗  Step 2: Initiate payment
   POST /v1/payments  →  422 Unprocessable Entity
   Assertions: 1 failed

   ✗  status == 201
      Expected: 201
      Actual:   422
      Response: { "error": "insufficient_funds", "message": "Account balance too low" }
A failed checkpoint 
✗  Step 3: Verify ledger entry  (manual checkpoint)
   Result: Failed
   Note: "No transaction appeared in the ledger after 60 seconds. Checked at 14:09 UTC."