Bulk repository operations can trip the platform's own rate limit

Large fleet-wide jobs could exhaust the source-code platform's request budget and start rejecting their own traffic. Because a rejected request looks exactly like a genuine build failure, this previously sent an investigation down the wrong path entirely.

What was actually happening

Triggering a job costs almost nothing. What consumes the budget is the work each triggered job then does — cloning the repository and polling for instructions. So a fan-out of fifty jobs does not strain the trigger interface at all; it creates fifty simultaneous consumers of a different, much smaller budget.

The previous workaround was to pad bulk loops with a 90-second delay between triggers. Measurement showed that to be about 460 times more conservative than necessary: 150 consecutive requests completed at over 5 per second with no rejections and no slowdown.

What changed

The repository-traffic budget was tripled, from 10,000 to 30,000 requests per hour. Normal operation uses only about a tenth of the old budget, but a single busy minute had already reached two-thirds of the old sustained rate, so the headroom was thinner than it looked.

The guidance is now to limit how many jobs run at once rather than padding delays between them — same protection, without turning a fleet-wide operation into a multi-hour job.