Reduce GitHub Actions costs where it actually matters

The cheapest workflow is the one that never needed to run. First, review every event in the workflow’s on configuration. Use branch and path filters when a workflow only applies to part of a repository. Likewise, avoid equivalent checks for both a push and its pull request unless both signals are required.

Scheduled workflows deserve the same scrutiny. For example, a cron job that scans an unchanged repository every hour can quietly dominate execution count. Before narrowing triggers, confirm which branch protections and deployment controls depend on the check. Cost reduction is not a reason to remove a required safety signal.

• Apply path filters to scoped builds
• Remove duplicate push and pull-request work
• Review scheduled workflow frequency
• Keep required checks and deployment controls intact

Before changing individual steps, identify the workflows consuming the largest share of runner minutes. The workflow treemap makes that concentration visible: each block represents a workflow's share of usage for the selected analysis, not its billed cost. For GitHub Actions cost optimization, this is a prioritization signal rather than a bill.

Start with the largest block. Next, open its jobs to see whether the total comes from many executions, long-running work, or both. A large block is an investigation target, not proof that the workflow should be removed.

• Prioritize total minutes over one unusually slow run
• Keep usage share distinct from modeled cost
• Drill into the jobs and steps behind the largest block

Fast-moving pull requests can queue several runs for commits that have already been replaced. GitHub Actions concurrency groups can cancel an in-progress run when a newer commit makes its result obsolete. However, group by workflow and branch or pull request so unrelated deployments do not cancel one another.

Cancellation is most valuable where developers push repeatedly and feedback from old commits no longer matters. After the change, review GitHub's cancelled runs and runner usage rather than assuming the policy saved time. If setup work is expensive, even early cancellation can save meaningful usage while giving the newest commit faster access to capacity.

• Group runs by workflow and branch
• Enable cancel-in-progress for replaceable CI
• Do not cancel independent environment deployments
• Review cancelled runs after the policy change

Dependency, compiler, and build caches can remove repeated work. However, a cache that rarely hits only adds upload and download overhead. Build keys from the operating system, architecture, dependency lockfile, and other inputs that genuinely invalidate the cached output. Use restore keys only when a partial match is safe.

Watch the step that restores the cache and the step the cache is meant to accelerate. Then compare hit rate, transfer time, median duration, and p95 duration. Large caches may help a cold build but hurt the common case. Pin cache actions to maintained versions and follow GitHub’s current security guidance for untrusted pull requests.

• Key caches from real invalidation inputs
• Measure hit rate and transfer overhead
• Avoid caching outputs that are cheap to rebuild
• Treat forked pull requests as a security boundary

A matrix makes coverage explicit, but every combination can create another job. Therefore, review whether every operating system, runtime version, architecture, and feature flag belongs in every pull request. Keep the combinations that protect compatibility, and move broader coverage to a merge, nightly, or release workflow when that risk model is appropriate.

Runner choice multiplies the effect. Different operating systems and larger runner sizes can carry different rates. Still, a faster runner is not automatically more expensive if it finishes much sooner. A cheaper runner may also fail to save money if queue delays or poor performance dominate. Compare cost per successful execution, not only price per minute.

• Calculate the full number of matrix combinations
• Use include and exclude deliberately
• Separate pull-request and release coverage
• Record runner choice and job cost per execution separately

Repeated failures are both a reliability problem and a cost problem. First, rank workflows by failed runtime. Then inspect the jobs and steps responsible, separating deterministic failures from flaky tests, unavailable services, permission problems, and capacity issues. Each category needs a different fix.

Retries can be appropriate for genuinely transient dependencies. Otherwise, a broad retry can hide an unstable system while doubling its usage. Record every valid rerun attempt, set a narrow retry limit, and expose the original failure. The goal is not a greener dashboard; it is less repeated work and faster trustworthy feedback.

• Rank failures by total runtime, not count alone
• Quarantine and repair flaky tests
• Retry only known transient operations
• Preserve the original error for diagnosis

Artifact uploads, environment setup, repeated checkouts, and package installation can accumulate across many jobs. Therefore, upload only outputs that another job or a person will use. Set an appropriate retention period, and avoid moving large directories when a smaller build result is enough.

At step level, optimize the product of execution count and duration. For example, a six-second setup repeated thousands of times can matter more than a rare ten-minute release step. Combine compatible setup work where it improves the critical path, but do not create one monolithic job that removes useful parallelism or makes failures harder to isolate.

• Upload only consumed artifacts
• Set retention to the real debugging need
• Rank steps by total runtime
• Preserve useful parallelism and failure isolation