Scan allowances: how many cloud scans you get, and how they are counted

A cloud scan costs one scan. The rule is deliberately that simple: every audit counts one, whoever or whatever started it.

​

What you get

​

What counts as one scan

All of these, equally:

• An audit you start yourself from the project screen
• An audit triggered by a change landing on your default branch
• An audit triggered by a pull request being opened or updated
• The first audit queued when you import a repository

And these do not count, because they produced no report:

• An audit you cancelled
• One superseded by a newer push to the same branch or pull request
• One no scanner claimed, or that timed out
• One stopped because the repository was paused or GitHub access ended

​

The window is your billing period, not the calendar month

The allowance resets when you are charged, not on the first of the month. If you subscribed on the 14th, it resets on the 14th. An account or team with no subscription, a trial for instance, resets on a calendar month instead. The reset date is shown on your Projects screen either way, so you never have to work it out.

​

Personal and team allowances are separate

Your personal account and each team have separate scan allowances. Unused scans cannot be transferred between them.

• Your account spends your Pro allowance
• Each team spends that team’s allowance
• Being in two teams means two separate pools, both usable, neither shared

​

Running out

You are warned when 80% of the allowance has been used, the card on your Projects screen turns amber and says so, while there is still enough left to act on. If it does run out, automatic audits stop for every repository in that account or team and each one reports “allowance used”. Your GitHub connection is untouched, existing reports are unaffected, and audits resume on their own when the allowance resets. The screen names the date.

​

Getting more

Three ways, depending on where you are:

• Adding seats raises a team’s allowance immediately, by 100 per seat
• Subscribing replaces a trial allowance straight away
• Auditing merges only, rather than every pull request update, is the single setting that most reduces what you spend. See Audit triggers

​

Working out what you need

Count the changes that land, not the pushes you make. Merges are one audit each, so a team merging six pull requests a day across all its repositories spends roughly 120 a month and sits comfortably inside a three-seat allowance of 300. Turning pull request auditing on multiplies that by however many times a branch is pushed before it merges, which is usually three to five. That is the number worth estimating before switching it on across every repository.