PATTERN Cited by 1 source

Per-repo budget cap

Intent

Allocate fleet-scanning compute budget per repository rather than per run, because cost varies wildly across repos — allowing productive repos to receive more investment while unproductive repos don't waste resources.

Mechanism

1. Enforce a strict task cap per repository.
2. Spin up a worker pool of 50–200 workers sized to overall fleet capacity.
3. Productive repos (ones actively finding things) consume more of the budget.
4. Unproductive repos hit their cap quickly and free workers for others.

Rationale

"Because the cost per repository varies wildly, we budget per repo rather than per run. That way you can spend money on the repos that are actually finding things, and not waste it on the ones that aren't." (Source: sources/2026-06-18-cloudflare-build-your-own-vulnerability-harness)

Consequence

Full scans are run as periodic backlog sweeps, not per-PR checks. A full scan of a complex repo can take hours (worst case: >14 hours). Cheaper, smaller harnesses are the right tool for per-PR checking.

Seen in

• systems/cloudflare-vulnerability-discovery-harness — 50-200 worker pool across 128 repos with per-repo caps

Related

• concepts/coverage-cell — what the budget buys (cells covered)
• patterns/sqlite-keyed-stage-persistence — where cap enforcement state lives