Cost analysis

Understand theoretical vs billable cost, track free-tier minutes for GitHub and Latchkey, and find your most expensive repositories and workflows.

The Cost Analysis page answers "where does our CI money go?" for both GitHub-hosted and Latchkey runners.

The page is organized into three sections: Cost Overview (the headline KPIs), Cost Analysis (the charts you drill into), and Latchkey Runner Costs (what your managed runners are costing this billing period). Before any of that is useful, though, you need the distinction the whole page is built on.

Two numbers to understand#

Why two numbers? Free tiers absorb the first slice of your usage, which makes billable cost a poor trend signal: it can sit near zero for part of a period and then climb steeply once free minutes run out, even when your actual usage grew smoothly. Theoretical cost moves in proportion to usage, so it is the one to read when you ask "are we using more CI than last month?" Billable cost is the one to read when you ask "what will we pay?"

Cost Overview section#

• Theoretical Cost with a week-over-week trend badge and the GitHub vs Latchkey portions labeled underneath. The trend badge compares billable cost for the last 7 days against the previous 7 and shows a dash until two full weeks of data exist.
• Highest Spend (Theoretical): your top 3 repositories by modeled cost for the selected period.
• Cost Per Build and Build Efficiency Ratio to normalize spend against output. Cost per build is the average theoretical cost per successful build; efficiency ratio is build success rate relative to theoretical cost, so higher means more successful builds per dollar.
• GitHub and Latchkey KPI stacks: forecasted billable cost for the period and free-tier minutes used and remaining on each side.
• Free Tier Minutes Tracking: segmented gauges for GitHub-included minutes and Latchkey-included minutes side by side, with the limits reflecting your own plan allotments.

A word on Cost Per Build: total cost rises whenever your team ships more, which is usually good news, not a problem. Cost per build strips volume out of the picture. If total cost is up but cost per build is flat, you are simply building more. If cost per build itself is rising, each build got more expensive: longer runs, bigger runners, or new steps, and that is the trend worth investigating.

The forecast deserves a note too. Once the current month accumulates enough usage history, the GitHub KPI stack projects billable spend through the end of the billing cycle as Forecasted billable cost by end of cycle, based on your month-to-date spend pattern. Until then, the card reads "Not enough data yet, run more jobs for a forecast". Either way, you see where the month is heading while there is still time to react.

Cost Analysis section#

• Cost Over Time: daily billable and theoretical cost as two series over your selected date range.
• Repository Costs: theoretical and billable cost per repository, with a Top 5 / Bottom 5 dropdown. Repository names link directly to GitHub, so you can go from a cost spike to the workflow files behind it in one click.
• Cost by Runner OS: a donut of spend across Linux, Windows, and macOS, separating Linux (GitHub) from Linux (Latchkey) when both exist.

Two reading tips for this section. On Cost Over Time, the point where the billable line starts tracking the theoretical line is the point your free-tier minutes ran out; before that, free minutes were absorbing the difference. And on Cost by Runner OS, remember that GitHub charges a premium for Windows and macOS minutes, so a large Windows or macOS slice is often a list of jobs worth moving to cheaper Linux runners.

Latchkey Runner Costs section#

If you run jobs on managed runners, this section appears with a per-configuration cost table: Config Name (with the runner label you use in workflow files, such as latchkey-small), a Custom or Preset type badge, Jobs, Avg Duration, and Cost for the selected period. When free minutes were used, a footer shows "Free tier applied: X / Y min" and the dollar value saved. Latchkey runner cost KPIs always reflect the current billing period, independent of the date-range filter.

Above the table, a callout reads "Estimated savings vs GitHub-hosted: $X": the dollars your team saved by running jobs on Latchkey runners instead of comparable GitHub-hosted runners for the selected period. It appears whenever the savings are positive.

Filters on this page#

The shared filter bar works here the way it does everywhere (runner type, repository and workflow multi-selects, reset), with one difference: the date range picker uses billing-oriented presets: MTD, 7D, 30D, 3M, 6M, and 12M. Every chart also opens in a fullscreen mode that keeps the filter bar, and the display settings gear has a "Show decimals" toggle that switches dollar figures between cent precision and rounded whole dollars.

Which chart answers which question#

Using this page to actually cut cost#

A suggested routine when spend needs to come down. Nothing here is enforced by the product; it is simply the order in which the charts answer each other's questions:

Metric reference#