A third-party API returns 429 and features quietly stop
A feature that depends on an outside service works, then stops for a stretch, then works again. Nothing is deployed in between, no page errors, and the affected records simply have missing data where the integration should have filled it in.
- Any stack
- Bubble
- Lovable
- Bolt
- Replit
- Webhooks
- Scheduled jobs
Root cause, in plain English
Outside services cap how many calls you may make in a window and answer 429 once you cross it. Code that treats any non-success response as nothing-to-do carries on as if the call returned empty. The feature does not crash, it silently produces incomplete work, and it recovers on its own when the window resets — which is exactly what makes it look intermittent rather than broken.
How to fix it
Log the status code and any retry hint from every outbound call. Until 429 is distinguishable from an empty result in your logs, this failure is invisible.
Treat 429 as retryable rather than final: wait for the interval the response asks for, then retry with increasing backoff and a cap on attempts.
Stop bursting. Batch work into paced runs rather than firing one call per record as fast as the loop allows, which is what pushes you over the limit.
Cache responses that do not change often, so repeated work stops spending quota on answers you already have.
Fail loudly when retries are exhausted — mark the record as incomplete and alert, instead of writing a partial result that looks finished.
Go deeper: the full guide to rate limits that silently drop data.
How Nightlamp detects this automatically
- API canary
- Heartbeat
- HTTP status
An api_canary exercises the integration path on a schedule and asserts the response actually contains what it should, so a throttled call fails the check instead of passing as an empty success. A heartbeat on the job that consumes the API catches runs that die partway through, and http_status trends reveal the error rate climbing before the feature stops entirely.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why does it fix itself without a deploy?
- Rate limits reset on a rolling window. Once enough time passes your quota returns and the calls succeed again, so the outage ends on its own. That self-healing is why it is so often dismissed as a glitch rather than investigated.
- How do I know a limit is what I am hitting?
- The status code says so directly, and most services also return a header telling you how long to wait and how much quota remains. If you are not recording those, start there — the answer is usually already in the response you are discarding.
- Should I just retry immediately in a loop?
- No. Immediate retries spend the quota you are waiting to get back and can extend the block. Wait at least as long as the response asks, increase the gap on each attempt, and give up after a bounded number of tries.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.