GitHub Actions Billing Changes Dec 1: Your Playbook

On December 1, 2025, GitHub Actions billing for self‑serve, credit‑card Enterprise Cloud accounts moves to a standardized payment date: the first of each month. In the same window, GitHub expanded the Actions cache so a repository can exceed the previous 10 GB cap on a pay‑as‑you‑go SKU with new admin controls for size and retention. If you own CI reliability or the cloud budget, you’ve got a week to get ahead of this.

GitHub Actions billing: what changed and when

Two concrete changes are landing:

1) Billing date standardization. Starting December 1, 2025, usage‑based charges for metered GitHub products (including Actions minutes, Actions storage, Codespaces compute/storage, Packages storage/egress, Advanced Security seats, and metered Copilot overages) get charged on the first of the month. Your usage window remains the calendar month; this is about when the payment hits, not a new billing period. If you saw a November charge, it covered October usage; December 1 will include November usage.

2) Cache limits above 10 GB per repo. Every repo still gets 10 GB of Actions cache included. Admins can now raise per‑repo cache limits beyond 10 GB with two policies: a size eviction limit (GB) and a retention limit (days). If you increase the size cap beyond the included amount, the extra is billed as a separate cache storage SKU. When a repo exceeds its limit, least‑recently‑used entries are evicted automatically. Billing owners can attach a budget to this SKU; if that budget is exhausted, the cache becomes read‑only for repos using the higher limits until the next cycle.

Why this matters now

Standardizing to the first helps finance and makes variance easier to compare month‑over‑month. The catch? Your CI storage profile no longer hides behind a hard 10 GB ceiling. That’s great for build performance—large monorepos, iOS/Android shops, and data stacks can keep more warm cache—but it also opens a door to unbounded spend if policies and budgets are sloppy.

A few realities to anchor decisions:

• Minutes reset monthly; storage doesn’t. Storage is metered by hourly peak usage. If your repo idles at 12 GB for weeks, you’ll see it on the bill.
• Runner minutes cost differently by OS. Baseline rates have long translated to roughly $0.008 per Linux minute and $0.016 per Windows minute, with macOS consuming minutes at a 10x multiplier versus Linux. If your fleet leans heavy on macOS, missing caches magnify cost and queue time.
• Default cache retention is seven days. Cranking it to 30 without a plan sounds nice—until you’re paying for old, rarely hit keys.

The Dec 1 CI cost triage: a 7‑step playbook

Here’s a fast, practical process I use with teams that need answers in days, not quarters.

1) Map your heavy hitters

Pull last month’s top repositories by Actions minutes and storage. Identify the top 10% by spend or runtime. These are the only ones worth fine‑tuning this week. For each, note OS mix (Linux/Windows/macOS), average job duration, and whether caches regularly miss.

2) Set cache size and retention per repo

Leave small repos at the default 10 GB / 7 days. For larger repos (mobile monorepos, Bazel‑based builds, heavy package restores), set a targeted size cap per repo—e.g., 15–25 GB for iOS monorepos—and keep retention tight (7–14 days) unless you have long‑lived release branches that rarely rebuild. The rule of thumb: size for 2–3 cache generations of your largest dependency layer, then let eviction do its job.

3) Align cache keys to actual invalidation

Cache misses are silent money burners. Use composite keys that include the right hashes—lockfiles for package managers, Xcode version + Swift version for iOS, Gradle wrapper + Gradle cache segment for Android. Add a lightweight restore-keys prefix so you can partially hit prior layers when only part of the toolchain changes.

4) Budget the new cache SKU

Attach a per‑org or per‑repo monthly budget to the expanded cache SKU. Set alerts at 50/80/100%. Remember: if the budget is exhausted, cache over‑limit usage flips to read‑only. Builds won’t fail, but they’ll get slower as fewer writes land. Tell your team this can happen and what to check.

5) Right‑size minutes by OS

Mac jobs are expensive in minutes and scarce in capacity. Prefer Linux for everything that isn’t genuinely macOS‑bound: API tests, linting, and web builds. For iOS, minimize the matrix. Do you need four iOS versions on every PR? Probably not. If you run a public OSS repo, remember that standard GitHub‑hosted runners are free for public repos—leverage that for nightly builds while keeping private CI focused on what protects production.

6) Put artifacts on a diet

Artifacts aren’t caches, and both count. Keep only what helps a human or a downstream job: test reports, coverage, and deploy bundles. Trim debug zips and duplicate packages. Prefer build rehydration from source + cache instead of fat artifacts that sit for weeks. Use short retention on artifacts unless there’s a compliance reason to keep them longer.

7) Sanity‑check costs with a quick back‑of‑the‑envelope

Minutes: if a repo spends 12,000 Linux minutes beyond quota in a month, that’s in the ballpark of 12,000 × $0.008 = $96. Windows minutes double that rate. For cache: you pay only above the included 10 GB, metered hourly. If your configured cap is 20 GB and your typical hourly peak is ~14 GB, expect to be billed for roughly 4 GB of cache each hour it stays that high. Keep the cap just high enough to avoid churn, not high enough to hoard.

People also ask

What’s changing on December 1, 2025 for GitHub Actions?

GitHub is standardizing usage‑based credit‑card billing for Enterprise Cloud to the first of the month. This includes Actions minutes and storage, Codespaces, Packages, Advanced Security, and metered Copilot. It doesn’t change the usage window (still calendar month) or per‑minute rates; it changes when the payment posts.

Does GitHub charge for Actions cache, and how is it priced?

Every repository still gets 10 GB of cache included. If an admin raises the cache size limit beyond 10 GB, the additional cache is billed as a separate SKU based on hourly peak usage. Two policies—size eviction (GB) and retention (days)—control behavior. Use budgets to cap exposure.

What happens if a cache budget is exhausted?

The cache stays readable but becomes read‑only for repos using the higher limits until the next billing cycle. Your builds won’t break because of writes, but cache effectiveness can degrade as old entries age out and new ones can’t be written.

Are public repositories affected?

Standard GitHub‑hosted runners in public repositories remain free for minutes. The new cache limit behavior still applies per repo, but most public repos can live happily within the 10 GB included tier if keys and retention are sensible.

Job design tweaks that save real money

Beyond billing toggles, job design usually unlocks the biggest wins.

• Split long jobs. A 40‑minute all‑in-one job that fails at minute 38 is a tax. Split build, unit tests, and integration tests. Fail faster; pay less.
• Guard the matrix. Gate broad matrices to merge or nightly. Run a narrow set on PRs.
• Cache selectively. Caching everything is slower and pricier than caching the 1–2 biggest pain points (e.g., ~/.gradle/caches, node_modules, CocoaPods, or Bazel outputs).
• Use partial restore. With layered keys, a minor toolchain bump doesn’t force a cold start.
• Pin tool versions. Stable toolchains keep caches hot longer. Constant compiler churn thrashes caches and burns minutes.

iOS, Android, and monorepos: specific guidance

iOS/visionOS/macOS apps. You’re paying the macOS minute multiplier, so cache health matters. Cache the DerivedData segments that move the needle, and include Xcode + Swift version in the key. Keep retention at 7–10 days unless release branches build monthly. If build queues get long, consider reserving macOS capacity only for stages that truly need it, and shift lint/tests to Linux.

Android. Gradle is cache‑friendly when you get the keys right. Hash the Gradle wrapper and major buildSrc inputs so you don’t blow the cache on minor library bumps. Cap the cache at 15–20 GB for big monorepos and keep retention at or below 14 days.

Monorepos. If you use Bazel or Nx/Turbo, lean on remote cache, not gigantic Actions caches. Keep the Actions cache for dependency layers that are expensive to fetch from the network (e.g., language toolchains), not for every build output. Use paths to limit scope; avoid caching node_modules across unrelated workspaces unless your lockfiles move in lockstep.

Budgeting and reporting that Finance will love

Finance wants predictability and guardrails. Give them both:

• Budgets with alerts. Add budgets at the enterprise and org level for the expanded cache SKU and for Actions minutes. Alert at 50/80/100% so you can nudge teams before write‑locks kick in.
• Cost centers. Tag repos to cost centers (product lines, markets) so reports roll up cleanly. That way the December 1 shift doesn’t introduce reconciliation chaos.
• Month‑close ritual. Standardized payment dates make variance analysis easier. Share a one‑pager: top 5 repos by minutes, top 5 by cache overhead above 10 GB, and actions taken.

How to estimate without a spreadsheet

Minutes math is straightforward. For baseline runners, Linux minutes cost roughly $0.008 and Windows $0.016; macOS consumes minutes at 10x the Linux rate. If a repo burns 3,000 Linux minutes/day on workdays only, that’s ~60,000 minutes/month ≈ $480. Cut PR matrices in half and shave 20% off with a healthy cache, and you’ll see it drop quickly.

For cache beyond the included 10 GB, think in hourly peak usage. If a repo’s peak sits around 14 GB most hours, expect to be billed for ~4 GB hours per hour it stays there. Lower the cap to 12–13 GB and you’ll likely force a bit of eviction without hurting hit rates—cheap insurance against key bloat.

Operational gotchas to watch

• Read‑only caches surprise developers. If the cache budget hits 100%, new writes fail silently into a slower build path. Add an on‑failure step that surfaces a clear message: “Cache writes disabled by budget policy; build times may increase.”
• Retention is not deletion. Retention is the minimum time before eviction is considered, not a guarantee of storage removal at midnight. Size caps still govern eviction immediacy.
• Artifact hoarding hurts. Teams often conflate artifacts and caches. Artifacts help humans and downstream jobs; caches help the next run. Treat them differently, set different retentions, and delete aggressively.

What to do next (this week)

• Identify your top 10% repos by Actions minutes and storage; ignore the rest for now.
• For those repos, set a cache cap and retention that matches actual key lifecycles. Start with 15–20 GB and 7–14 days where justified.
• Enable budgets and 50/80/100% alerts for the expanded cache SKU and Actions minutes.
• Trim artifacts; keep only what PR reviewers or releases need.
• Cut PR matrices and move Linux‑eligible tasks off macOS.
• Document the new billing date so Finance expects the December 1 payment to reflect November usage.

Where we can help

If you’d like a fast outside view, our team has done this for SaaS, fintech, and marketplace engineering orgs that ship daily. We pair cost telemetry with job‑level refactors so you save money and ship faster. See how we approach cost and reliability on our services page, browse selected outcomes in our portfolio, and skim recent engineering playbooks on the blog. If infrastructure spend is squeezing roadmap room, talk to us—we’ll give you a concrete action plan in a week.

Related playbooks

If cost control is top of mind, you might also find value in our piece on how to cut CPU costs on Cloudflare’s containers pricing. Different platform, same mindset: know the dials, pick the right defaults, and protect yourself with budgets.

FAQ for busy execs

Will this increase my bill? Not by default. The billing date change doesn’t alter rates. Raising cache caps beyond 10 GB can increase spend, but often reduces minutes by improving hit rates. That’s the trade to design for: pay a small, predictable storage bill to shave expensive macOS minutes and developer idle time.

Can we opt out of the new billing date? If you need a different arrangement, talk to GitHub about invoiced billing. Otherwise, self‑serve credit‑card Enterprise Cloud accounts switch on December 1, 2025.

How do we keep this from becoming another “set and forget” bill? Treat it like capacity planning. Revisit caps and retention quarterly, reset budgets at fiscal rollover, and make cache hit rate a visible SLO on the repo dashboard.

Zooming out

CI is product infrastructure. These GitHub updates bring the knobs you’d expect in a modern platform: predictable billing, scalable caches, and budgets that actually enforce. Use them. Most teams don’t need heroics—just a clear cap, sane retention, keys that reflect reality, and a budget with alerting. It’s a few hours of cleanup that pays back every week.