Cost Analysis

CI cost is usually hard to reason about from a single workflow run. A five-minute run can be cheap or expensive depending on how many jobs ran in parallel, which runner labels they used, whether the jobs retried, and how much rounding the billing system applied.

Everr turns GitHub Actions job data into a cost view you can inspect in the dashboard and hand to a coding assistant. The goal is not just to show a bill; it is to show which workflows, repositories, and runner choices are worth changing.

How billing minutes work

GitHub Actions billing is based on runner time, not on workflow wall-clock time. The important unit is the job.

For each job:

1. GitHub measures how long the job ran on its runner.
2. Partial minutes are rounded up to the nearest whole minute.
3. The rounded minutes are charged at the rate for that runner type.

In practice:

job billed minutes = ceil(job duration in seconds / 60)
job estimated cost = job billed minutes * runner rate
workflow estimated cost = sum(job estimated cost for every job)

That means parallel jobs do not make billing minutes disappear. If a workflow has five Linux jobs that each run for two minutes, the workflow may finish in about two minutes of wall time, but it used about ten billed runner minutes.

Retries also count again. A job that fails after five minutes and then succeeds after ten more minutes used two job attempts, and each attempt is rounded separately.

Runner type matters too. Standard Linux, Windows, macOS, larger, GPU, ARM, and third-party hosted runners all have different rates. Public repositories, included plan minutes, enterprise discounts, budgets, and storage charges can change what appears on your final provider invoice, so Everr treats cost as an estimate from runner usage rather than as the billing source of truth.

For the current provider details, see GitHub's Actions billing docs and Actions runner pricing reference.

Working with a coding assistant

Cost optimization is a good assistant task because the assistant can connect the dashboard signal to workflow YAML, logs, test history, and repository structure.

Run the assistant inside the code repository, not from a detached chat. Everr knows what happened in imported GitHub Actions runs: workflows, jobs, runner labels, durations, logs, attempts, and cost estimates. It does not know the source-controlled workflow definitions, composite actions, scripts, package layout, or project-specific CI intent unless the assistant can inspect the checkout. The useful loop is Everr for the runtime signal, the repository for the actual change.

Use Everr to identify the hotspot, then ask your assistant to inspect the workflow and propose a small change:

Use Everr's cost analysis to find the most expensive workflow in this repo over
the last 30 days. Then inspect the workflow YAML and suggest one low-risk
change that would reduce billed minutes without weakening CI coverage.

For rounding waste:

Everr shows billed minutes much higher than total minutes for this workflow.
Find the short jobs that cause the rounding overhead and suggest whether they
should be combined, removed, or left separate.

For runner choice:

Everr shows most CI spend on macOS and Windows runners. Inspect the workflows
and identify steps that can safely run on Linux, keeping platform-specific tests
on their original runners.

For performance work:

Use Everr's CI run history and logs to find the slowest repeated setup or test
steps in this workflow. Propose a caching or test-splitting change and explain
how we would verify the cost impact after the next few runs.

Keep the loop tight: change one workflow, let it run a few times, then compare the same Everr time range before and after the change. Optimizing CI is easiest when every change has a clear hypothesis, such as "reduce macOS minutes by moving lint to Linux" or "reduce rounding waste by merging three sub-minute jobs."

If you use Everr's bundled skills, install them so assistants know how to fetch CI context directly:

everr skills install --all --project

How to find optimization work

Start with the highest-cost workflows, not the slowest ones. A workflow can be slow because one cheap Linux job is long, or expensive because many short macOS or Windows jobs run in parallel.

Good first questions:

• Which workflows have the highest estimated cost?
• Which runner labels account for most of the spend?
• Which workflows have much higher billed minutes than total minutes?
• Which workflows have a high average cost per run?
• Which scheduled or pull request workflows run more often than they need to?
• Which jobs are using expensive runners for work that could run on Linux or a smaller runner?

Common fixes include:

• move platform-independent work from macOS or Windows to Linux;
• split platform-specific jobs so only the required steps use expensive runners;
• right-size larger runners when extra CPU is not reducing total cost;
• add caching for dependency installs, build outputs, and test setup;
• reduce matrix combinations that do not protect a real compatibility boundary;
• use path filters so docs-only or frontend-only changes do not run unrelated jobs;
• cancel superseded pull request runs;
• fail fast before expensive integration or release jobs start;
• reduce artifact retention or artifact size when storage is also a cost driver.