Q: Six months after migrating 80 microservices to GitHub Actions, you realise the total GitHub Actions spend has tripled compared to your old Jenkins setup. An audit shows most workflows run on `ubuntu-latest` GitHub-hosted runners. What strategies do you apply to systematically reduce costs without slowing down developer feedback loops?

A systematic cost reduction framework:

• Identify top spenders: GitHub's billing API exposes per-workflow minute usage. Export it and sort by cost. Focus optimisation on the top 10 workflows consuming 80% of spend.
• Self-hosted runners for heavy jobs: Migrate compilation and Docker build jobs to spot EC2 instances (via Actions Runner Controller). Cost drops by ~70% for compute-heavy tasks.
• Aggressive dependency caching: Calculate cache hit rates (GitHub shows this in each actions/cache step summary). A 30% cache hit rate means 70% of runs are downloading packages from scratch. Fix the cache key to be more stable.
• Cancel redundant runs: Use concurrency groups with cancel-in-progress: true. If a developer pushes twice in 30 seconds, the first run is cancelled immediately.

--- *More CI/CD scenarios added periodically. PRs welcome.*

• Step-level parallelism: Replace sequential test steps with a build matrix, running tests in 4 parallel jobs. Total wall-clock time drops 4× but total minutes drop ~20% (faster = less idle time on expensive runners).
• Right-size runners: Jobs that only run shell scripts don't need a 4-CPU runner. Use runs-on: ubuntu-latest (2 vCPU) for light jobs and runs-on: [self-hosted, large] only for heavy jobs.