Debug a workflow by locating the earliest point where an observed result differs from the expected result. Fixing the final symptom first can hide an upstream mistake and create a second problem.
Define the expected journey
n8n documents a workflow as connected nodes that automate a process, with executions among its core workflow topics. Use that connected structure to organise your investigation rather than treating the process as one opaque action.
As practical editorial advice, write one sentence for each stage: what enters, what changes, and what should leave. Select one synthetic record and one expected destination. Avoid using customer records or private execution material in shared debugging notes.
Ask the input questions first
Start this question tree at the earliest available evidence:
- Is the record present? If not, investigate the handoff before the workflow.
- Is its identifier the expected identifier? If not, inspect selection or matching assumptions.
- Are required fields present and correctly typed? If not, investigate the input contract.
- Is the timestamp interpreted consistently? If not, establish the intended timezone before proceeding.
Do not continue merely because a stage completed. Completion and correctness are different observations.
Follow transformations before branches
For each transformation, record the incoming value, intended rule and outgoing value. Ask whether whitespace, empty values, date formats or unit conversions changed meaning.
Only after those checks should you examine branching. Write the condition in plain English, including what happens when a value is absent. Compare the actual input to that condition, not to what you remember the original record containing.
At the first mismatch, stop moving forward. Later incorrect outputs may simply be consequences.
Work through a bounded example
Hypothetical example: a synthetic enquiry has id=TEST-041, city=Pune, amount_rupees="1,250" and priority=standard. The intended rule sends amounts of ₹1,000 or more to review.
Your trace worksheet records:
- Input: amount is the text
1,250; this matches the fixture. - Transformation: expected numeric amount is 1250; observed amount is 1.
- Branch: observed amount fails the review threshold.
- Destination: standard queue receives the record.
The branch may be behaving correctly on an incorrect transformed value. Evaluate a proposed fix against both 1,250 and 950, plus an empty amount. Success means the first two take their intended paths and the empty value follows a deliberately defined exception path.
Decide whether to resume
Resume only after the failing fixture and an ordinary fixture both produce expected results. If the earliest mismatch remains unexplained, keep consequential actions paused where operationally feasible.
If access arrangements obstruct investigation, check the automation catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence.
Sources and scope
Source material checked 29 October 2026; features/policies may change. n8n workflow documentation establishes the connected-node model and execution context. The question tree, fixture and restart criteria are editorial advice, not documented interface instructions.