We recently expanded our development team and onboarded approximately 25 new engineers as committers to our primary monorepo, which is under a GitHub Advanced Security (GHAS) commitment for GitHub Enterprise Cloud. In the subsequent billing cycle, our GHAS cost increased by roughly 300%, which was significantly higher than our forecast based on a linear "per-committer" model.
Our current setup is as follows:
- A single GitHub organization.
- GHAS is enabled at the organization level.
- We use a single "enterprise" monorepo for our core application, with approximately 2.5 million lines of code.
- The billable committer count reported by GitHub jumped from ~15 to ~40.
- We utilize Code Scanning (with CodeQL), Secret Scanning (push protection is on), and Dependency Review.
My primary hypothesis is that the billable committer definition—"unique users who have authored a commit in any repository with GHAS enabled in the last 90 days"—is interacting with our workflow in a way we didn't fully model. We've observed that several of the new engineers, as part of their onboarding, created feature branches from `main` and pushed small test commits or documentation updates. This immediately classified them as billable committers.
My questions for the community are:
1. Is such a disproportionate cost increase normal when scaling the team, or does it suggest a misconfiguration in how GHAS is applied?
2. Beyond the obvious (restricting GHAS to only certain repos, which we are evaluating), what strategies have you employed to manage GHAS costs with a large or fluctuating number of committers?
3. Specifically regarding monorepos: Are there patterns for structuring branch permissions or commit workflows that can help contain the billable committer count without hindering developer productivity? For instance, would using a bot account for automated dependency PRs (like Dependabot) help, or are those also counted as billable committers?
I have begun analyzing GitHub's usage reports, and the data appears to align with the 90-day rolling window. Our preliminary cost-optimization ideas include:
- Evaluating if splitting the monorepo into smaller, service-specific repos (with GHAS enabled only on critical ones) would be more cost-effective, despite the architectural and CI overhead.
- Implementing a pre-commit hook or CI check that warns when a first-time committer is about to push, allowing us to guide them to a non-GHAS repo for initial commits.
- Reviewing if all our active repositories truly require GHAS, as it may have been enabled globally without sufficient granularity.
Any data-driven insights, especially from organizations that have undergone similar scaling, would be invaluable. Concrete examples of how you structured your GHAS rollout and commit policies to maintain cost predictability would be most helpful.
infra nerd, cost hawk
You're right to focus on the committer definition - that's almost certainly the main driver. The 90-day rolling window can catch people you might not consider "active" committers in a traditional sense.
One thing to check is whether any automation or service accounts are also being counted now. Bot accounts that create commits (like for dependency updates or automated formatting) will inflate your billable count if they commit to the GHAS-enabled repo. It's a common oversight when teams scale.
Also, with push protection enabled for secret scanning, every commit attempt that triggers a block and subsequent fix creates another committing user event. That onboarding activity with test commits would definitely count, but it should stabilize as those new engineers settle into their normal workflows.
That 90-day window is brutal for onboarding spikes. I've seen it happen.
You mentioned test commits triggering push protection blocks. Does each fix commit from a blocked push also count as a separate committing event in that window, or is it just the user that matters? I'm trying to understand if the act of fixing a block creates another "committer" timestamp that resets their 90-day clock.
Yes, your hypothesis is correct. The 90-day window captures anyone who commits, including onboarding test commits. The jump from 15 to 40 committers lines up almost exactly with adding 25 new engineers, so your model was right but your initial committer baseline was likely wrong.
Check your billable committer list in GitHub Insights. You'll probably find the 15 original engineers plus all 25 new ones. Some of the original 15 might have been inactive in the previous 90-day window, so your old bill was artificially low. Your new bill of ~40 is your true active committer count.
Numbers don't lie.
That's a precise observation about the baseline being artificially low due to the rolling window. It effectively means they were getting a discount for inactive users, and the new bill reflects the actual, total active team size.
A related nuance is that the "90-day active committer" metric isn't simply person-based, it's commit-based. A user who made a single commit 89 days ago is still billable, which can make cost forecasting tricky around team vacations or sabbaticals. The Insights data is key, as you said, but it requires interpreting a moving target.
This often surfaces a need for internal chargeback models that smooth out these rolling windows versus the sharp peaks in GitHub's billing.
—BJ