Workflow / Autopsy

Intake

Last updated 2 August 2026

Six questions and two attachments. About ten minutes of your time. A written diagnosis comes back within 24 hours on business days.

We never ask for account access, credentials, or a call. Nothing below asks for a password. If any of it reads as though it does, tell us and we will fix the wording.

Before you send: redact

Your export and logs may contain real customer emails, names, record IDs, API tokens or webhook URLs. Please replace them before sending. The fastest safe method:

What we need is the shape and sequence of your data, never its contents. Anything you miss is redacted on receipt and not retained. Artifacts are deleted 30 days after delivery.

The six questions

1. Platform and exact version

Why we ask: a large share of failures are version-specific node changes or plan-specific limits, and the fix differs completely between self-hosted and cloud.

2. What is it supposed to do, and what does it do instead?

One sentence each. Plain language, no jargon needed.

Supposed to: “When a Stripe payment succeeds, create a row in Airtable and send a Slack message.”
Actually does: “Creates the Airtable row twice, and the Slack message has an empty customer name.”

Why we ask: the gap between intent and behaviour usually names the failure class on its own.

3. When did it last work correctly, and what changed around then?

A date or a rough date. Then anything that changed near it, even if it seems unrelated:

Why we ask: “nothing changed” and “we rotated a credential” point at completely different failure classes. This question does more diagnostic work than any other on the list.

4. Is it deterministic or intermittent?

If it is intermittent, does it correlate with anything: time of day, batch size, a specific record, runs that happen close together, the first run after a quiet period?

Why we ask: intermittent failures are a different family entirely — rate limits, race conditions, token expiry, pagination. Deterministic ones are usually logic or schema.

5. What have you already tried, and what happened?

Including the things that did not work. Especially those.

Why we ask: it stops us selling you back something you already tried, and a fix that “should have worked but didn't” is a strong signal about where the real cause is.

6. What does a correct run look like?

If you have one successful execution, tell us its date or ID so we can compare it against a failing one. If it has never worked, say so — that is a different diagnosis.

The two attachments

A. The workflow export

B. The full execution log of ONE failing run

Not a screenshot of the red error line. The whole run.

We need each node’s INPUT, not only its output or its error. For a whole family of failures — a field that arrives blank, a value of the wrong type — the answer is not in what the node produced but in what it was handed. In n8n’s Output panel switch to the JSON view rather than the table: the table renders an empty string and a missing key identically, and telling those two apart is the diagnosis in those cases.

If you can also send the log of one successful run, do. A diff between a good run and a bad run is the single highest-value artifact you can give us, and it frequently halves the diagnosis.

Check your retention before you do anything else

The most common reason a diagnosis has to stop short is that the run which explains the failure has already expired. Default retention is short, the deletion is silent, and by the time anyone thinks to look the evidence is gone. Raise it now, not when you next need it.

If the log is already gone, still send the export and say so. We will tell you plainly what can and cannot be determined without it, rather than guessing — and a diagnosis that has to stop at “not determinable” is refunded.

What you get back, within 24 hours

  1. The verdict — one sentence naming what is wrong.
  2. The failure class — the named, general category it belongs to.
  3. The proof — the exact line in your own log that demonstrates it, quoted and explained.
  4. The fix — step by step, in your own UI, in your version.
  5. A hardened replacement file — where the platform allows an import (n8n, Make), a corrected workflow you import yourself. We never touch your account.
  6. A verification test — a specific thing you run to confirm it is actually fixed, with the expected output.
  7. What we could not determine — an honest list of anything the artifacts did not let us settle, and what you would need to capture to settle it.

Point 7 is not filler. If your artifacts do not contain the answer we say so plainly rather than guessing — and if that is the whole report, you get a full refund and we tell you exactly what to capture next.

Scope, plainly

One order is one report on one symptom, plus one round of clarifying questions within seven days. A new, unrelated symptom is a new order. If we spot a second latent problem while diagnosing the first, we tell you about it for free — fixing it is a separate order and you are under no obligation.

Unconditional refund: if the report does not help you, say so and it is refunded. We will not argue about it.

Where to send it

Answers and attachments to hello@workflowautopsy.com. Plain email is fine; there is no form to fill in and no account to create.

The 24-hour clock starts when the artifacts land, not when you first write. Artifacts that arrive over a weekend start Monday at 09:00 Lisbon time. If anything is missing we tell you once, immediately, naming the exact click path for your platform.