My automation stopped working: how to find what changed

Somewhere in the first message people send us is the phrase "my automation stopped working", followed by the part that makes it feel personal: nobody touched it. That part is almost always true. A workflow that ran quietly for eight months does not develop an opinion overnight, so when an n8n workflow stopped working suddenly, the change has a date on it and the date belongs to somebody else.

What follows is the order we work in when a client hands us a dead flow, with the output we read at each step. The same order applies if your Zap stopped working or a Make scenario went quiet, because it is about evidence rather than about the platform.

Open the earliest failed execution

The execution list is sorted newest first, which is the opposite of what you need. Scroll past the recent failures to the first red run of the outage. The gap between the last green execution and that one is the window in which something moved, and in most rescues that window turns out to be about an hour wide.

This is the payload n8n hands to an Error Trigger, redacted from a lead-routing workflow we were called into:

{
  "execution": {
    "id": "48213",
    "mode": "trigger",
    "retryOf": null,
    "url": "https://n8n.acme.internal/workflow/17/executions/48213",
    "error": {
      "name": "NodeApiError",
      "message": "Request failed with status code 401",
      "httpCode": "401",
      "description": "Authorization failed. Please check your credentials.",
      "node": "HTTP Request"
    },
    "lastNodeExecuted": "HTTP Request",
    "startedAt": "2026-08-19T06:14:02.771Z"
  },
  "workflow": { "id": "17", "name": "Lead routing to CRM" }
}

Three fields do all the work here. The httpCode narrows the cause to one family of problems, lastNodeExecuted tells you where the run died rather than where it went wrong, and startedAt gives you a timestamp you can hold against every other event of that morning: a deploy, a password change, an invoice that went unpaid.

Now put the runs on either side of it next to each other. The executions list gives you this in about twenty seconds:

Execution	Started	Status	Last node	Response
48096	Aug 18, 22:41	Success	Merge	200
48098	Aug 19, 05:59	Success	Merge	200
48213	Aug 19, 06:14	Error	HTTP Request	401
48214	Aug 19, 06:31	Error	HTTP Request	401

05:59 worked. 06:14 did not. Nothing in that quarter of an hour happened inside n8n. Somebody rotated an API key overnight, or a security policy expired a token at six in the morning, and the workflow was the first thing to try to use it afterwards.

My automation stopped working and nothing on our side changed

If your version of the sentence is that the workflow stopped working and I changed nothing, both halves of it can be true at the same time. The usual suspects, in the order we find them:

• A credential expired or was revoked. Google refresh tokens issued to an app still in Testing publishing status expire after seven days, which is a favourite of integrations built in a hurry and never promoted to Production.
• The provider retired an API version and the old path now answers 410.
• Somebody in sales renamed a custom CRM field or deleted a pipeline stage. The API accepts the request and quietly writes nothing into a field that no longer exists.
• Volume grew. A flow that handled 50 records a day started handling 500, hit a rate limit, and n8n treats 429 like any other failure unless you tell it otherwise.
• Someone upgraded n8n, or the container restarted onto a new host with a different outbound IP address that is not on the provider allowlist.

Two of those are visible from inside n8n. The rest live in somebody else's changelog, which is why our first question to a client is about the calendar: what else happened on the nineteenth?

Reading the status code

The response code rules out half the candidates before you open a single node.

Code	What it means here	What to do
401	The credential is missing, expired, or wrong. The service does not know who you are.	Reconnect the credential. Retrying is wasted time, since the second attempt carries the same dead token.
403	The service knows exactly who you are and will not let you do this. A scope was removed, a seat was downgraded, a plan lapsed, or an IP allowlist changed.	Reconnecting with the same scopes changes nothing. Check permissions on the account, then the plan.
410	Gone, permanently and on purpose. Providers use it for retired API versions and hard-deleted records.	Read the provider changelog and migrate the call. No amount of retry logic brings back a removed endpoint.
429	Rate limited. Often accompanied by a Retry-After header that nobody reads.	Retry with a growing wait. If it happens daily, the flow needs batching rather than patience.
ETIMEDOUT	Nothing answered at all. The service is down, slow, or unreachable from your host.	Retry, then check the provider status page before touching your own code.

One trap sits underneath that table. Plenty of APIs answer 200 with an error inside the body, so the node goes green and the record never arrives. If your executions all look successful and the work is still not being done, the other page in this pair covers that case: the workflow runs but nothing happens.

Change one thing, and prove it with pinned data

Open the failed execution, select the failing node, and pin its input. Then run that node alone. If it fails again with the pinned input, the node or the service is at fault. If it passes, the data arriving in production differs from what you believe is arriving, and the comparison between the pinned failure and a healthy run from last month will show you where.

Pinned data only applies to manual executions. Production runs ignore it, so you can experiment on a live workflow without changing what it does to real records, which is the one thing that makes this safe to do at nine in the morning while people are waiting.

Once you know the cause, harden the node before you close the tab. Retry settings live on the node itself:

{
  "name": "HTTP Request",
  "retryOnFail": true,
  "maxTries": 4,
  "waitBetweenTries": 5000,
  "onError": "stopWorkflow"
}

n8n allows up to 5 tries and a wait of up to 5000 milliseconds between them from the interface, with defaults of 3 and 1000. Those defaults are fine for a blip and useless for a provider that takes a minute to come back, so raise the wait on anything that talks to a service with a status page. Keep onError at stopWorkflow on nodes that write records. Switching it to continue turns a red run green while the write silently does not happen, and a green run is one nobody investigates.

The alert nobody read

The lead-routing flow above failed roughly once a day at about 200 runs a day. It had alerting. The alert went to a Slack channel that had been archived months earlier, so nobody had seen a single failure.

Nobody had seen one.

That is the failure mode we meet most often, and it is second on our list of the reasons automations die in production. The fix takes about ten minutes. Import the error workflow at the top of this page, open Settings on each production workflow, and choose it under Error Workflow. Every failed execution then sends the workflow name, the node, the message, and a clickable execution URL to somewhere a human looks at daily.

Two things about error workflows that catch people out. They do not fire for manual executions, so testing by clicking Execute Workflow will never prove the alerting works; trigger a real run against a deliberately broken credential instead. And they cannot report an instance that is down, which is why the file also includes a scheduled heartbeat you can point at an uptime monitor.

There is a deadline on your evidence, too. n8n prunes execution data after 336 hours by default, which is 14 days. If the flow broke three weeks ago and nobody noticed, the failed runs that would have named the cause are already gone, and the diagnosis becomes archaeology on the provider side instead. Alerts matter partly because they preserve the log line while the log still exists.

When you do not need to hire anyone

Most of what we have described is an afternoon of work for somebody comfortable in the editor, and a good number of the enquiries we get end with us saying so. Handle it yourself when:

• The error is a plain 401 on one node and you own the account behind the credential. Reconnect it, rerun the failed executions from the list, done.
• One field name changed in the CRM and the mapping needs the new name typed into it.
• The workflow was accidentally deactivated, which is more common than it sounds after anyone edits a live flow and forgets the toggle. The executions list simply stops, with no failures at all, because nothing ran.
• You are hitting 429 once a week and switching retry on with a five second wait makes it go away.

Get help when the failures are intermittent with no pattern you can name, when the same fix has been applied twice and the flow broke again a different way, when the workflow has grown past 40 or 50 nodes and nobody can trace one record through it, or when the person who built it is gone. That last one is common enough that we wrote a separate piece about what to do when the freelancer disappeared; three of the six rescues we have scoped so far started that way, with every account still in the builder's name.

What it costs to hand it over

We start with a written diagnostic for $500. Within 3 business days you get a document naming what broke, the evidence, and a fixed quote to repair it, and the $500 comes off that quote in full. Small fixes of the kind on this page run $750 to $1,500 and take 2 to 5 days. Anything structural is a standard rescue at $1,500 to $4,000 over 1 to 2 weeks. Everything we touch carries a 30-day bug warranty, and the hardening we leave behind is the same list we use on our own systems, published as the production-ready checklist.

If the same workflow has now broken twice, read why an n8n workflow keeps failing before you patch it a third time. Otherwise, send us the execution URL and the error text at the rescue intake form, or read how the engagement runs on the rescue page.