Monitoring Rate Limits: Yours and Your Dependencies

You are the rate limitee — an upstream API (Stripe, Twilio, GitHub) is rejecting your requests with 429. Symptoms: specific operations fail intermittently, retry storms start, user-visible errors that appear non-deterministic.

You are the rate limiter — your own rate limiter is rejecting legitimate user traffic. Symptoms: users reporting 'too many requests' errors, spike in 429 responses in your API metrics.

Track 429 responses from your API separately from other 4xx errors: ``` alert when: 429_rate > 5% of total requests for 5 minutes ```

This catches scenarios where your rate limits are set too aggressively for normal usage patterns — like after a traffic spike that resets user quotas.

Instrument your HTTP client to track 429s from each upstream: ```python def make_request(service, url): response = requests.get(url) if response.status_code == 429: metrics.increment(f'rate_limited.{service}') retry_after = int(response.headers.get('Retry-After', 60)) time.sleep(retry_after) return response ```

Alert when any upstream 429 rate exceeds 1%.

Scheduled jobs that process large batches are common rate limit culprits. A nightly job that calls an API 10,000 times without rate awareness will exhaust daily quotas.

Monitor: add a heartbeat to the end of your batch job on AlertsDock, and log the number of 429s encountered during the run.

Implement a circuit breaker that opens when rate limit errors exceed a threshold: - 10 consecutive 429s → open circuit for 60 seconds - During circuit open: return cached data or graceful error - After 60s → test with single request (half-open)

This prevents retry storms that worsen the rate limit situation.