When Automation Gets HTTP 429: Retry, Wait or Stop?
More requests can delay recovery
When automation receives HTTP 429, do not keep resending immediately. It generally indicates requests exceeding a service limit. Read the API contract and any server-suggested delay, then bound both attempts and total elapsed time. Urgent work needs a handoff rather than an indefinite hidden queue.
Microsoft recommends separating temporary failures from problems retrying cannot fix, such as invalid data or missing permission. Start with the actual service’s error meanings instead of treating every unsuccessful response as a reason to resend.
Set delays and limits together
If a response includes Retry-After, have the technical team interpret it according to the service contract and wait at least that long. Otherwise, use increasing delays with staggered retries to avoid many clients restarting together. Do not copy another system’s timings without representative load tests.
Check whether the connector or library already retries. In a hypothetical design, three outer attempts with three inner attempts each can produce nine requests. Assign policy ownership and measure actual outgoing requests instead of reading only one settings screen.
Failure and unknown outcome are different
A response timeout may leave it unclear whether the destination committed the operation. Before retrying a business-changing command, check the original job reference or the system’s duplicate-effect protection. Longer waits can reduce load but do not themselves prevent duplicate orders or payments.
At the limit, retain the job for review with its reason, latest timestamp, attempt count and owner. Manual resubmission needs an audit trail and a check that the request is still valid; a canceled old job should not revive merely because the service recovered. Avoid exposing complete confidential data in alerts.
Test stopping as well as recovery
In a test environment, simulate 429 with and without a delay, invalid data, a lost response after commit, and an outage exceeding the retry budget. Inspect real request counts, waiting time and business effects, not just eventual green status. If old work blocks new work, revisit queue management.
Before asking Chawinnix to implement automation, define the business’s waiting tolerance, handoff owner and effects that must not repeat. The technical team can then propose verification and stopping rules for the actual scope. A retry policy should explain both recovery and continued failure.
