How to Manage Failed Runs in Integration Tools: A Beginner Checklist

Quarantine the Failed Run Before You Retry It

A failed run does not always mean the action failed. A timeout can mean the integration tool never received a response, even though the destination system created the record.

Before replaying anything, answer these four questions:

1. Which step failed? Identify the app, action, and affected record.
2. What error appeared? A 401, 403, 400, 409, 429, and 500-series error each need a different response.
3. Did the destination receive the request? Search for the customer, order, ticket, task, or transaction before sending it again.
4. Could a repeat create harm? Stop retries for actions that could charge money, send a duplicate email, create another CRM record, overwrite data, or trigger an irreversible change.

Treat the failed event as its own recovery job. Capture the record ID, source timestamp, failed action, and destination response. Do not rerun a whole batch because one row failed.

A beginner retry policy

Use this policy until your team has a more specific process for each workflow:

• Authentication or permission error: Use 0 retries. Restore credentials or permissions first.
• Validation error: Use 0 retries. Correct missing, malformed, or unsupported data.
• Duplicate or conflict error: Use 0 retries. Search the destination and decide whether to link, update, or skip the record.
• Rate-limit error: Follow the API’s Retry-After instruction. If there is no stated wait period, pause the workflow and reduce request volume.
• Temporary server or network error: Retry after 60 seconds, 5 minutes, and 15 minutes. Escalate after the third failed attempt.
• Timeout with a possible side effect: Search the destination before retrying. Treat the original request as potentially successful.

This prevents one bad record from consuming tasks, creating duplicates, or repeatedly firing customer-facing actions.

Build These Failure Controls Into the Workflow

The quality of an integration is often most visible when something breaks. A tool that only reports “run failed” leaves someone to reconstruct the event manually. Better recovery controls make it easier to isolate the record, understand the error, and replay only the work that needs attention.

When choosing or configuring an integration platform, look for these controls:

• Step-level logs: Run history should show the failed action, payload, and returned error.
• Item-level handling: Batch workflows need a way to identify one failed row while preserving successful rows.
• Selective replay: Replaying one failed operation is safer than rerunning an entire workflow.
• Retry settings: You need control over retry count, delay, and the errors that qualify for retry.
• Detailed alerts: Alerts should include the workflow name, failed step, record identifier, timestamp, and a direct link to the run.
• Searchable history: Daily workflows benefit from at least 30 days of execution history. Monthly processes benefit from 90 days or more.
• Duplicate protection: Idempotency keys, unique external IDs, and destination-side upsert actions help prevent duplicate records after uncertain failures.

An email alert can be enough for a low-volume personal workflow. It is not enough for a workflow that processes leads, orders, support tickets, or scheduled data syncs every day. In those cases, failed records need a clear place to wait for review.

Automatic Retries Versus Manual Recovery

Automatic retries are useful for short-lived technical problems. They are risky when the destination may have completed the action but the integration did not receive confirmation.

For example, retrying a read request after a connection error is usually less risky than retrying a “create invoice” or “send email” action. A second write request can create a duplicate if the first request reached the destination successfully.

Manual recovery adds a review step before anything is repeated. Someone checks the record, confirms the destination state, corrects the cause, and then decides whether to replay the action. That takes more time, but it is the safer path for uncertain outcomes and customer-facing actions.

For higher-volume workflows, use a holding queue or dead-letter queue. Failed records stay in one place until they are repaired, skipped, or replayed. This takes more setup than sending failure notifications by email, but it prevents failed records from disappearing across inboxes and chat channels.

Choose the Recovery Path by Error Type

Match the response to the error, not to the urgency of making the workflow look successful again.

Timeouts deserve special care. The request may have left the source system, reached the destination, and completed successfully before the response path failed. A second request can create a duplicate even when the run history shows a failure.

Rate limits also point to a workflow design issue when they happen repeatedly. If a sync fails every afternoon because it sends a large batch at once, longer retries only delay the same problem. Reduce batch size, stagger schedules, or process records incrementally.

Review Failures at a Regular Cadence

Set a review schedule that matches the number of runs your workflows handle.

A workflow with more than 100 runs per day needs a short daily review of failed records. A low-volume internal workflow can usually use a weekly review, as long as alerts reach a named owner.

Group failures by category instead of treating every alert as an isolated event:

• Credential expiration or permission changes
• Missing source fields
• Invalid formats or mapping rules
• Rate limits and quota exhaustion
• Destination outages
• Duplicate records
• Timeouts with uncertain completion

Patterns point to the real repair. Ten failed runs caused by a missing phone number call for validation before the integration step. Ten failures caused by a rate limit call for a scheduling or batching change. Replaying the records without fixing the pattern simply creates the same work again.

Keep a brief incident note for recurring problems. Include:

• Workflow name
• Trigger
• Failed action
• Error category
• Permanent fix
• Owner

This gives future reviewers a clear record of what happened and how the workflow was repaired.

Protect Write Actions With Idempotency and Stable IDs

Write actions need stronger safeguards than read actions. Orders, contacts, invoices, subscriptions, and similar records can create cleanup work when a failed run is replayed without checking the destination first.

Idempotency is the key protection. An idempotent request reaches the same final result even when sent more than once. Where the destination supports them, use idempotency keys, external record IDs, or upsert actions for records that must not be duplicated.

Also plan for these operational limits:

• Webhook retention: A missed webhook cannot be recovered when the source does not retain events or provide a replay option.
• Execution history: Short log retention makes older failures harder to investigate.
• API quotas: High-frequency workflows need pacing, batching, or queued processing.
• Redacted data: Security controls may hide payload fields in logs, so retain safe record identifiers outside sensitive payloads.
• Source changes: A record replayed later may no longer match the source state at the time of the failure.

A replay is safest when the workflow uses stable IDs and updates an existing destination record rather than creating another one.

Stop Routine Retries for High-Risk Actions

Do not use routine retry rules for failures involving irreversible, regulated, or customer-facing actions.

Payments, refunds, payroll changes, account deletions, legal notices, protected health information, and customer communications need a reviewed recovery path. If the failure leaves the result unclear, a person should confirm the source and destination state before taking another action.

The goal is not to clear the error quickly. The goal is to restore the intended business result without creating a second transaction, losing data, or weakening the audit trail.

Critical workflows need named ownership, a source-of-truth check, and documented resolution. Built-in retry settings cannot replace those controls.

Failed-Run Setup Checklist

Set up these safeguards before a workflow becomes part of regular operations:

• Name a workflow owner and backup owner.
• Define which errors retry automatically and which stop immediately.
• Cap temporary-error retries at three attempts within 21 minutes.
• Include a unique record ID in alerts and logs.
• Add duplicate protection for create actions.
• Test recovery for a missing field, expired credential, rate limit, and timeout.
• Choose a destination-side search method for uncertain outcomes.
• Create a queue or labeled view for records that need human review.
• Set a daily or weekly failure review based on run volume.
• Document how to replay one record safely.

A workflow is not finished when the happy path works. It is finished when a failed record has a clear owner, a safe recovery route, and a way to avoid the same failure next time.

Mistakes to Avoid

Do not apply the same retry rule to every failure. A credential problem, invalid email address, duplicate record, and destination outage need different actions.

Do not rerun an entire workflow to recover one record. Full reruns can create duplicate leads, duplicate tasks, repeated notifications, and conflicting updates. Recover at the record level whenever the tool allows it.

Do not rely on alerts that say only “automation failed.” Without the workflow name, failed step, record ID, and error message, someone has to search through run history during every incident.

Do not treat one successful replay as proof that the underlying problem is fixed. If the same error appears again, add validation, change the schedule, update permissions, or redesign the affected step.

Bottom Line

Use automatic retries for short-lived server and network failures only. Limit them to three attempts over 21 minutes. Stop immediately for access problems, validation errors, duplicate conflicts, and uncertain customer-facing or financial actions.

The safest workflows preserve record IDs, protect against duplicate writes, isolate individual failed records, and give a person a clear queue for the cases that need judgment.

FAQ

How many times should an integration tool retry a failed run?

For temporary server or network failures, use three attempts: after 60 seconds, 5 minutes, and 15 minutes. Do not automatically retry authentication, permission, validation, duplicate, or conflict errors.

Should I replay a failed run or rerun the entire workflow?

Replay the individual failed record whenever possible. Rerunning the full workflow can repeat actions that already succeeded, especially CRM record creation, notifications, invoices, and scheduled syncs.

What should I do after a timeout error?

Search the destination before retrying. A timeout means the integration tool did not receive a complete response; it does not prove that the destination rejected the request. Search with the source record ID, email address, order number, or another unique identifier.

Why do integrations create duplicate records after a failure?

Duplicates happen when the original request reaches the destination but the confirmation does not return to the integration tool. Idempotency keys, unique external IDs, upsert actions, and destination searches before replaying uncertain requests help prevent this.

What errors should stop a workflow immediately?

Stop the workflow for permission errors, expired credentials, missing required fields, malformed data, duplicate conflicts, destructive actions, and customer-facing transactions with unknown completion. These situations need correction or review, not repeated requests.