Here is a bug that has burned more than one team: an n8n workflow that reports success even when the operation it performed actually failed. The execution log is green, everything looks fine, and yet the record was never created, the deal never moved, the sync never happened. This is one of the most dangerous classes of automation bug because it hides in plain sight. Here is why it happens and how to make sure it never happens to you.

The root cause: completing is not succeeding

The confusion comes from a subtle distinction. When an HTTP request “completes,” it means the server responded. It does not mean the server did what you wanted. A 404 (not found) or a 500 (server error) is still a completed request with a real response. If your workflow treats “I got a response” as “it worked,” it will happily mark a failed operation as a success.

By default, some request configurations do not throw an error on a non-success status code. The request finishes, the workflow continues, and the failure is invisible unless you explicitly look at the status code the server returned.

How the bug plays out

Imagine a workflow that updates a deal in your CRM. The API endpoint expects a deal ID. If that ID is wrong or missing, the API returns a 404, because there is no such deal to update. But if the workflow does not check the status code, it sees a completed request, moves on, and logs success. The deal never updated. Nobody notices until someone asks why the pipeline is out of date, and by then dozens of updates may have quietly failed.

The fix: inspect the status code, every time

The solution is to stop trusting completion and start checking the actual result. After any API call, add logic that inspects the response status code and branches explicitly:

• A 2xx status means it worked. Continue.
• Anything else means it did not. Route to your error handling: notify a human, log the failing record, and stop pretending it succeeded.

Configure your request steps to fail on error status codes where the platform allows it, so a bad response surfaces as a failure instead of a silent pass. Then back that up with an explicit status check so nothing slips through.

Test the failure path, not just the happy path

Most teams test that a workflow works when everything is correct. Far fewer test what happens when it is not. Deliberately feed the workflow a bad ID or a malformed request and confirm it fails loudly. If it reports success on input you know is broken, you have found the bug before it found you. This one test would prevent most silent-failure incidents.

The lesson generalizes beyond n8n and beyond 404s: never let “the request finished” stand in for “the operation worked.” Check the result, branch on failure, and make failures loud. Growth Wizard builds automation that fails honestly, because a workflow that lies about success is more dangerous than one that plainly breaks.