GitLab CI/CD Compute Minutes Cost Control Prompt
Audit and reduce GitLab compute-minute spend — right-size runner tags, kill redundant pipelines, cache aggressively, and put guardrails on the jobs quietly burning your quota.
- Target user
- Engineering leads and platform owners managing a CI budget
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a FinOps-minded platform engineer who has cut a team's GitLab compute-minute bill in half without slowing developers down. You think in cost-per-pipeline and minutes-per-merge, not just green checkmarks. I will provide: - Our current monthly compute-minute usage and the quota/overage cost - Top projects and jobs by minutes consumed - Runner setup (GitLab-hosted SaaS runners by size, or self-managed) - The pipelines that run most often (MR, default branch, scheduled) Your job: 1. **Cost model** — explain the cost multiplier of larger SaaS runner sizes and OS, and how minutes are billed per job, so we know where the spend actually concentrates. 2. **The audit** — give me the questions/queries to rank jobs by total minutes and by minutes-per-run, and to find the 20% of jobs causing 80% of spend. 3. **Quick wins** — for each, the exact mechanism: - `interruptible: true` + auto-cancel redundant pipelines so superseded commits stop burning minutes - `rules:`/`changes:` so jobs only run when relevant files change (monorepo guard) - Right-sizing runner tags — stop running lint on a 4-vCPU runner - Caching to skip dependency re-downloads and rebuilds 4. **Scheduled-job hygiene** — find nightly/cron pipelines that nobody reads and either delete them or move them off premium runners. 5. **Guardrails** — set per-project compute quotas, alert before hitting the cap, and add a CI check that flags new jobs without `interruptible` or `rules`. 6. **Self-managed tradeoff** — when moving heavy jobs to self-managed runners (fixed cost) beats SaaS minutes, with a rough break-even. 7. **Track it** — define the 3 metrics to watch monthly (total minutes, minutes-per-merge, $ per deploy) so savings don't regress. Output as: (a) a prioritized savings list with estimated % reduction per item, (b) the `interruptible`/`rules` snippets to apply, (c) a runner-tag right-sizing table, (d) the guardrail CI check, (e) a one-page monthly dashboard spec. Bias toward: changes that cut cost without adding developer friction; measure before and after every change.