Aglet

Prioritize API rate limit bursts by work at risk

Rate-limit incidents should queue by what they prevent and how much additional traffic they create. An optional dashboard read can wait; a write or reconciliation job may require immediate containment. Weigh reset evidence, caller reach, queue age, and retry ownership before increasing capacity.

Decide where the work belongs

  1. Map affected work

    List operation, caller, account, priority, attempt count, and current state for each cohort. Separate reads from writes and new work from retries. Use response headers and queue evidence to show whether the burst is narrow or shared across callers.

  2. Choose containment

    Compare reducing concurrency, pausing optional work, honoring reset timing, adding jitter, or moving work into an existing queue. Record what remains pending and who owns the choice. Do not make every caller retry at the same time after a reset.

  3. Set the rate queue

    Queue shared fan-out and unknown write effects first, then isolated optional reads. Set a finite attempt policy, owner, review time, and trigger for reprioritization. If secondary protection is suspected, prioritize evidence about request shape and concurrency before quota requests.

What to carry forward

Return a rate-limit queue with essential work, amplification risk, timing evidence, containment, owner, and review trigger. Escalate shared retry waves and unknown writes. Keep priority provisional when remote limit semantics or local concurrency are not measured.

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