Separate retryable failures from work that needs a person

Classify before retrying

A retry is useful when the next attempt could reasonably succeed without changing the request: a brief network interruption, rate limit, or temporary server failure. It is wasteful when the input is invalid, a required account is missing, or permission has been denied. AWS Well-Architected guidance says retries should be limited, use backoff and jitter, and run only where the operation is idempotent. Its Builders' Library also warns that a timeout can leave the caller unsure whether the side effect happened.

Build the classification from the destination's documented error responses. Do not infer that every 4xx or 5xx code has the same meaning across services. If the connector hides the response, preserve whatever error text and run identifier it provides.

Put a ceiling on automatic effort

Use a maximum attempt count or maximum elapsed time. Increase delays between attempts and add jitter so many failed jobs do not return at the same instant. The exact schedule depends on the service and urgency; the durable rule is that attempts end. Keep one retry layer in charge. If the platform, connector, and custom step all retry independently, a small limit can multiply into a large burst.

Before retrying a write, verify the destination supports idempotency or add your own duplicate protection. See the duplicate-prevention guide. A successful request followed by a lost response is not safe to repeat merely because it looked like a failure.

Design the exception queue as a work surface

An exception queue is not a log dump. Each item needs the source record, intended action, error class, attempt count, first and last failure times, safe replay control, and an owner. Include a plain-language next step. Group repeated failures by likely root cause so one expired credential does not create hundreds of separate mysteries.

A hypothetical intake workflow might retry a temporary destination timeout three times over fifteen minutes. An invalid postal code goes directly to “needs source correction.” An expired credential pauses all records for that connection and raises one owner alert while preserving affected source IDs. These are illustrative rules; the service's documentation and the cost of delay should set the real policy.

Close the loop deliberately

1. Correct the source, permission, or workflow before replay.
2. Check whether the destination side effect already exists.
3. Replay one item and inspect its destination result.
4. Release the remaining group in a controlled batch.
5. Record the resolution and update classification if the error recurs.

Monitor queue age as well as count. A queue of two high-impact items can matter more than fifty low-priority formatting errors. Give old items an escalation path and a final disposition such as corrected, safely skipped, or requires workflow change. Link the runbook to the stop-switch note; if exception volume rises sharply, pausing may be safer than continuing to produce cleanup work.