Skip to main content
As a runbook runs, Reqflo builds up an evidence log: a structured record of everything that happened. This isn’t just a pass/fail signal — it’s the underlying data that makes the run auditable and the final report useful. When someone asks “what actually happened at step 3?”, the evidence log has the answer.

​
When to use it

The evidence log is automatically captured during every runbook run — you don’t need to opt in. It becomes important when:
  • You need to attach supporting data to a support ticket or case.
  • A step failed and you need to understand exactly what the API returned.
  • An assertion passed but you want to verify the actual response value.
  • A manual checkpoint was marked and you need to review the agent’s note.
  • You’re compiling a report to share with another team.

​
Key concepts

Step-level records. Each step in the run produces its own evidence entry: the outgoing request (method, URL, headers, body), the response (status code, headers, body), and the result of any assertions that ran against it. Assertion results. For each assertion on a step, the log captures whether it passed or failed, the expected value, and the actual value. If an assertion fails, you can see exactly what was checked and what was returned. Derived values. If a step extracted a value from a response (a step output or derived value), the log records what was captured — useful for tracing how a value moved through a multi-step journey. Manual checkpoint entries. When a manual checkpoint is completed, the log records the pass/fail mark and any note the user added. These entries are treated as first-class evidence alongside automated results. Run metadata. The log also captures run-level context: the journey name and version, the Case selected, the Environment used, the time the run started and ended, and who ran it.

​
How it works

Evidence is collected continuously as the runbook progresses. You don’t take a snapshot at the end — the log builds incrementally, so a run that’s interrupted or abandoned still has a partial record up to the point of failure. At the end of the run, the evidence log feeds directly into the run report. The report summarizes what happened; the log backs it up.

​
Examples

What a step entry looks like A step entry in the evidence log might contain: 
Step: Initiate payment
Status: Failed

Request
  POST /v1/payments
  Body: { "amount": 4700, "currency": "usd", "account_id": "acct_abc123" }

Response
  HTTP 422 Unprocessable Entity
  Body: { "error": "insufficient_funds", "message": "Account balance too low" }

Assertions
  ✗  status == 201  →  actual: 422
  –  response.body.id  (skipped — step failed)
What a checkpoint entry looks like 
Step: Verify ledger entry
Type: Manual checkpoint
Result: Failed
Note: "No transaction appeared in the ledger after 60 seconds. Checked at 14:09 UTC."
Run metadata 
Journey: Payment initiation flow  (v3)
Case: Missing funding source
Environment: staging
Run started: 2026-06-13 14:03 UTC
Run ended:   2026-06-13 14:09 UTC
Run by: support-agent@example.com
Overall result: Failed (1 step failed, 1 checkpoint failed)