What are Dependabot's rate limits, and how might they affect large monorepos?

Dependabot operates under practical limits on how much update-checking work it performs per repository — including caps on concurrent update jobs and, per updates entry, the open pull request limit discussed elsewhere. For a large monorepo with dozens of separate package ecosystems (multiple microservices, each with their own dependency manifest), the cumulative volume of checks and potential PRs can be substantial.

flowchart TD
    A[Monorepo: 20 microservices, each with own manifest] --> B[20 separate 'updates' entries needed]
    B --> C[Each entry has its own schedule + PR limit]
    C --> D[Aggregate PR volume can become significant without careful tuning]

Practical mitigation involves staggering schedules across ecosystem entries (not all checking at the exact same time), keeping open-pull-requests-limit conservative per entry, and leaning on grouped updates aggressively to consolidate what would otherwise be many separate PRs — without this tuning, a large monorepo can generate an overwhelming, hard-to-triage volume of Dependabot activity.