Free tool · Workflow reliability

Success is not the same as done.

Your automation says it ran. The CRM row, booking or notification is missing. Compare the event log with downstream business receipts before deciding what happened.

No loginRuns in your browserEvidence, not a score
01 / Investigate

Compare two snapshots.

Paste sanitized CSV rows only—no client names, emails, tokens, secrets or business-sensitive records. This tool does not upload or store your inputs. Use the fictitious sample to understand the findings first.

Browser-local analysis
Required columns: event_id,status
Required columns: event_id,receipt_id

02 / A practical guide

Why a green workflow run can still miss the business result

A workflow engine usually reports whether it executed the steps it was asked to run. A business needs something else: was the intended record actually created, was the correct message delivered, or was the booking finalized?

These are different kinds of evidence. For an agency handing over an n8n or API automation, the most useful acceptance check is often a simple reconciliation between the event that triggered work and the system that should show the outcome.

First: did the workflow actually run?

No execution record: check whether the external service called the intended Webhook URL, whether you used the temporary test URL instead of the production URL, and whether the workflow is published. The official n8n Webhook documentation explains the separate test and production endpoints. This reconciler cannot diagnose a missing trigger from two empty exports.

Execution exists, but no CRM/booking receipt: compare stable event IDs with the downstream export using the free tool above. A missing receipt is a reason to investigate, not proof that the write failed.

Receipt exists, but the customer-facing outcome is wrong: this tool can confirm a matching ID was exported, not whether the content, recipient, booking state or external delivery was correct. Check those facts within the authorized downstream system.

A small, repeatable evidence check

  1. Pick one outcome, such as “one CRM record for each accepted lead.”
  2. Give every event a stable event_id, and preserve it in the downstream receipt where feasible.
  3. Export only the relevant test run IDs and business receipt IDs. Remove names and sensitive payloads.
  4. Compare the two sets; inspect missing, repeated and unexpected receipts.
  5. Confirm delayed processing windows and system-specific success rules before classifying an exception as a defect.

When you see a missing receipt, the next action is not automatically to retry the whole flow. First inspect idempotency safeguards and partial side effects, so a repair does not create duplicate business records.

Important: A matching receipt is not proof that the downstream transaction was correct. This tool is a narrow, read-only diagnostic aid. It does not replace end-to-end testing or establish payment delivery, regulatory compliance or recovered revenue.

What you can test next

For an actual client release, investigate one agreed missing-input case, a repeated event, a timeout, an application error hidden inside HTTP 200, and a partial-save failure. Record observed outputs separately from proposed tests and unavailable evidence.

03 / When a checklist is not enough

Need an independent release review?

Tell us the business outcome, the workflow platform, one suspected failure path and what isolated test evidence is available. We will only propose a bounded engagement when the scope and testing authorization are clear.

Ask about a bounded review ↗This opens your email application. No information is sent from the tool itself.