Five CI/CD Mistakes That Cost Small Teams Time

A pipeline that takes fourteen minutes and fails on a flaky test is annoying once. It becomes a real cost when ten engineers hit it four times a day and start treating CI as background noise they can ignore. Small teams feel this more sharply than large ones, because nobody owns the pipeline full-time — it is the thing you fix at 11pm before a release. These are the five GitHub Actions mistakes we see most often, and the cheapest fix for each.

Mistake 1: Running the full pipeline on every push

Run only the jobs a change actually needs — path filters and concurrency groups typically cut Actions usage by half or more. Add paths: filters so a docs edit does not trigger the integration suite, and set a concurrency group with cancel-in-progress: true so a new push kills the previous run instead of queueing behind it. The arithmetic adds up fast: a 12-minute workflow on a private repo, pushed 60 times a day across 22 working days, is 15,840 runner minutes a month. With path filters and cancelled runs you can realistically land under 5,000. At roughly $0.008 per Linux minute beyond the free allowance, that is the difference between about ₹10,500 and ₹3,000 a month — for zero change in code quality.

Mistake 2: Rebuilding the artifact in every job

Build the artifact once and promote the exact same bytes through staging and production. The common pattern is a test job that compiles the app, a deploy job that compiles it again, and a second deploy that compiles it a third time — three chances for the output to differ, and three times the minutes. Upload the build with actions/upload-artifact, tag container images with the commit SHA rather than latest, and have deploy jobs download what was already tested. When something breaks in production and staging was green, this is the reason nine times out of ten. It also makes rollback trivial: redeploy the previous SHA. If your deployment topology is the harder problem, it is worth reading up on reliable cloud deployment patterns before restructuring workflows.

Mistake 3: Long-lived cloud keys in repository secrets

Use OIDC to mint short-lived cloud credentials at run time instead of storing permanent access keys as repository secrets. Configure your cloud provider's identity provider to trust GitHub, give the job permissions: id-token: write, and scope the role so only this repository and this branch can assume it. The key then expires in an hour and there is nothing to leak or rotate. Two supporting habits matter:

• Put production secrets behind an environment with required reviewers, so a merge alone cannot deploy.
• Never expose production secrets to pull requests from forks; GitHub blocks this by default, but people work around it.

A leaked static key is not a pipeline annoyance, it is an incident with a bill attached.

Mistake 4: Running CI that nobody is required to pass

Make the fast checks blocking — branch protection with required status checks is what turns a workflow file into an actual gate. Without it, red builds get merged on a Friday because the release is more urgent than the test. Keep the required list short and fast: lint, unit tests, build. Leave slow end-to-end suites as advisory until they are trustworthy. Never put continue-on-error: true on a test step to make the badge green; delete or quarantine the flaky test instead, with an owner and a date. A required check that takes four minutes gets obeyed. A twenty-minute one gets bypassed.

Mistake 5: Not measuring runner minutes or duration

Track two numbers every month — median pipeline duration and total Actions minutes — because both drift silently as the repository grows. GitHub's billing page breaks usage down by workflow, which tells you where to look. Cache dependency installs with actions/cache keyed on the lockfile hash; a cold npm ci on every job is one of the most common quiet leaks. Self-hosted runners are worth considering once sustained usage is large enough to justify the maintenance, and the trade-offs are covered in our notes on running your own build servers. Below that threshold, tuning the workflows is almost always the better return.

Where to start

Pick the slowest workflow this week and do three things to it: add path filters and a concurrency group, move cloud auth to OIDC, and mark lint plus unit tests as required checks. That is a day of work for most teams and removes the majority of the waste described above. If the underlying architecture is the real constraint — multiple services, environments and rollback requirements — it helps to sketch that before touching YAML, and our architecture review work is usually where teams start. Maysan Labs builds and maintains CI/CD pipelines alongside the platforms they deploy, and can take this off your plate if the pipeline keeps losing to the release calendar.