Originally published on dxcore.dev . I've been building a CI scheduler — an internal tool that grew out of getting tired of watching my own Turborepo monorepo CI get slower on GitHub Actions. The pattern across teams that have been at it for ten years is consistent enough to write down. Shopify got 95% of their monolith CI runs under 18 minutes, down from 45 — but only after it had silently grown the other direction for years. Slack cut their average end-to-end build from around 10 minutes to around 2. Canva brought a "build all" job that had grown to take up to three hours down to around fifteen minutes. These are after-photos. The before-photo is what every monorepo team eventually arrives at: median CI time creeps up, week by week, with no single bad commit to blame. Six mechanisms do the creeping. Here's what each one looks like, and which lever each one calls for. You added packages This one is mechanical. Your monorepo started with three packages. By quarter six it has fifty.…