# Replace per-process limits without doubling the allowed rate

Moving to shared coordination changes how workers obtain capacity. Roll out the new scheduler so old and new paths do not each assume they own the full budget.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Map the existing admission paths

List workers, interactive requests, scheduled jobs and support tools that call the provider. Identify their current limits and retry behaviour.

Calculate the aggregate rate possible when all instances run, rather than treating one process's setting as the system limit.

Keep the provider's actual scope and current rules as the basis for the transition.

## Introduce shared observation first

Record requests by the intended shared scope and compare them with existing local counters. This reveals callers that do not pass through the expected client.

Test the new coordination mechanism in a safe environment under concurrency and worker failure. Verify slot recovery and persistent retry timing.

Do not move production admission to a shared component whose own failure behaviour is undefined.

## Transfer one scope coherently

Where possible, move all callers for a selected provider scope to the new scheduler together. If old and new paths overlap, explicitly divide or coordinate their budgets.

Avoid giving each path the full quota during the transition. That can create the exact aggregate excess the migration is intended to fix.

Keep operation identities and next-attempt records compatible so delayed work survives deployment changes.

For illustration, an existing fleet and a new scheduler each configured for 600 request units per minute can jointly admit 1,200 during overlap. Moving half the instances does not automatically halve their independently configured limits. Partition the temporary allowance explicitly or route both versions through the same admission boundary.

Also test a delayed operation created by the old scheduler and resumed by the new one. Its original next-eligible time and exhausted-attempt state should survive, otherwise deployment itself becomes a way to reset the budget.

## Remove bypasses after verification

Compare completion rate, throttling and backlog fairness before expanding. Test scheduled and support paths that run less frequently.

Retire local retry loops or limits that conflict with the shared policy, while retaining appropriate per-process protection where it serves a separate purpose.

Document rollback behaviour and shared-state compatibility. The migration is complete when every relevant caller participates in one coherent admission model, including work already waiting when the deployment changed.

## Sources

- [GitHub: REST API rate limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api)