Aglet

Triage an API rate limit burst

A rate response can reflect quota, concurrency, caller fan-out, or a slow dependency. Freeze one burst with request class, environment, attempt history, and available timing headers. Compare essential and optional work, then separate remote limiting from a local retry wave.

Establish what is happening

  1. Capture the burst shape

    Record start time, endpoint, caller, concurrency, status, remaining or reset headers, and attempt number for a small window. Keep credentials and payloads out. Note whether failures affected reads, writes, background work, or an interactive action.

  2. Trace retry ownership

    Follow the first response through client backoff, queue scheduling, worker retry, and any caller fan-out. Compare actual wait with reset or retry-after evidence. A second wave may come from local workers even when the first response came from a remote limit.

  3. Bound essential work

    Count failures by operation, environment, client revision, and work priority. Separate quota response, secondary protection, transport failure, and slow dependency. Mark responses without timing evidence as an uncertainty rather than inventing a reset interval.

What to carry forward

Triage ends with a bounded burst, response evidence, retry owner, essential-work impact, and explicit timing gap. Stop synchronized retries while the limit is active. Route capacity, backoff, and remote quota questions separately. Protect essential work while the queue owner investigates.

Technical background: GitHub documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow