A Stripe-backed accounting sync returns 429: find the limit first

When a Stripe-backed accounting integration starts returning HTTP 429, adding workers can make the delay worse. Ask the developer for a redacted example containing the endpoint, response headers, error code, duration and affected account. Keep credentials and customer details out of the incident record. Establish which business flow is waiting and the age of its oldest unresolved item.

Stripe identifies rate-limited responses with its Stripe-Rate-Limited-Reason header. An absent header means the 429 did not come from its rate limiter; a lock timeout is one possible cause. This diagnostic belongs to Stripe. Other accounting and payment providers require their own documented interpretation.

Read the header value before deciding which traffic to reduce. The distinction is operational: fewer requests per second and fewer requests running at once are different controls.

Compare the incident with recent backfills, report exports and integration changes. Ask whether several jobs started together, whether requests now retrieve more detail, or whether one account or object attracts repeated updates. Inspect request duration alongside request count. A modest arrival rate can still leave many requests active when responses take longer.

For repeated lock_timeout errors, Stripe recommends reducing competing changes to the same object, including serializing those updates. Its guidance also describes exponential backoff with jitter for retries. Have the developer show where those controls operate; a delay inside each worker does not by itself establish a shared traffic budget.

Agree which work receives priority while the cause is corrected. A historical analytical export may be deferrable while customer payment operations continue. Document that business choice with the integration owner instead of letting whichever job retries most aggressively consume the available capacity.

Measure successful completion throughput and new work arriving over the same interval. In an illustrative queue, 120 jobs finish each minute while 100 arrive. The backlog shrinks by only 20 jobs per minute. A backlog of 600 jobs would take about 30 minutes to clear under those steady conditions, before allowing for retries or other interruptions.

Use jobs with comparable work requirements for that estimate. One job may make several API calls or wait on another system. If arrival exceeds sustainable completion, waiting longer cannot clear the queue. The owner must reduce incoming optional work, improve the request pattern, or agree another supported capacity arrangement.

Reproduce the recorded error response in a controlled integration test. Check that the appropriate limiter changes behavior, retry attempts remain bounded, and one failing resource does not block unrelated work indefinitely. A sandbox success establishes only the behavior tested there; confirm effective production limits and observe a deliberately bounded release.

Use the related webhook and scheduled-sync guide for replay, duplicate prevention and population reconciliation. This incident's additional evidence is the diagnosed restriction, changed traffic control, observed backlog trend and accepted completion estimate. Escalate when that estimate misses the finance deadline, even if some requests continue succeeding.