Integration guides
What happens when an n8n workflow loses its API connection?
An n8n recovery guide covering expired credentials, rate limits, timeouts, alerts and safe replay without duplicate CRM records or messages.
By Automate HQ · Updated · 4 min read
At a glance
An API failure affects the node making the request; what happens next depends on its error settings. Earlier external writes may already have succeeded. Recover by identifying the failure, checking partial work and replaying only unfinished operations with duplicate protection. Reconnecting credentials alone does not prove that the backlog is complete.
- 01Classify the failure
- 02Preserve pending work
- 03Repair access
- 04Reconcile and replay
A failed run can still have changed the business system
Consider an illustrative workflow that receives an enquiry, creates a CRM contact and sends a confirmation. If the confirmation API fails after contact creation, the contact can still exist. Restarting everything may create another contact or send a second message. n8n cannot generally roll back writes across independent services.
Separate the execution status from the business outcome. For each inbound event, track which external actions completed and which remain uncertain. A timeout is especially awkward: the remote service may have accepted a request before the response was lost.
Identify the error before deciding to retry
Capture the endpoint, node, response status, execution reference and a redacted error message. Read the provider response as well as the HTTP code. A provider can use the same status for several causes; a reconnect button will not fix a malformed request.
n8n documents that HTTP Request normally treats 2xx responses as success. Its Never Error option changes that behaviour. If you use it to inspect responses, add an explicit branch that checks the status and provider error fields before any downstream action.
| Symptom | Investigate | Recovery policy |
|---|---|---|
| 401 / authentication error | Expired, revoked or incorrect credential | Repair authentication; test a harmless request |
| 403 / forbidden | Scopes, account role or resource policy | Restore the required permission |
| 429 / rate limited | Provider quota and retry guidance | Bound retries; respect Retry-After when supplied |
| 5xx / unavailable | Provider incident or temporary failure | Back off; retry only replay-safe actions |
| Timeout / lost response | Whether the write already happened | Reconcile before retrying a write |
| 400 / validation error | Payload, required fields or schema change | Correct input; route bad records for review |
Sources: n8n: HTTP Request response options
Build alerts that can survive the outage
Create a separate workflow beginning with Error Trigger and select it in the main workflow settings. n8n notes that Error Trigger runs for automatic workflow failures, not manual test executions. Verify the alert using a controlled automatic execution with test data.
Send the owner the workflow name, failed stage, incident time and a link to the saved execution when available. Keep credentials and customer payloads out of the notification. Use an alert destination that does not depend on the same failed connection.
A handled error branch may leave the workflow looking successful. Monitor the exception queue and age of pending work as well as failed executions. If no events arrive because the trigger itself stopped receiving them, a downstream error alert is insufficient; use a separate expected-activity or health check.
Make repeated delivery safe
Give each logical operation a stable identity, such as source event ID plus action name. Store it in a durable ledger with pending, completed and uncertain states. Enforce uniqueness atomically so concurrent executions cannot both claim the same operation. Use the destination API's idempotency mechanism when it provides one.
A local ledger alone cannot guarantee exactly-once behaviour across two systems. If the external write succeeds and the ledger update fails, the next run still needs reconciliation. Look up the external record or request status using the stable reference before writing again. For APIs without that ability, route uncertain actions to a person.
For temporary failures, use a bounded retry policy with increasing delays and jitter when appropriate. Document the retry limit and where exhausted items go. Repeatedly calling an API with a revoked credential adds traffic without restoring access.
Recover the backlog in a controlled sequence
Pause affected writes if repeated failures could create duplicates. Record the incident start time and preserve pending input using an approved durable store. Repair the credential or provider issue, then test a read or a disposable test record before releasing real work.
Reconcile uncertain operations first. Replay a small batch, check destination records and notification counts, then increase throughput within provider limits. Compare received events with completed, pending and deliberately rejected events. Close the incident only when every item has an explained outcome.
What should you test before going live?
In a test environment, simulate revoked access, rate limiting, an unavailable provider and a response lost after a successful write. Deliver the same inbound event twice and run two workers against it. Verify that each intended business action happens once or reaches an explicit review state.
Write a short recovery note naming the owner, backup owner, pause control and replay procedure. Measure the age of the oldest pending item; a queue that silently grows can damage customer follow-up even while most executions look healthy.