CodeRabbit Delta Deep Scans: Coverage Automation, Billing and Limits

CodeRabbit added Delta Deep Scans on October 26, letting teams refresh security coverage between full repository scans. The new feature checks changed code and updates existing security analysis. For GitHub repositories, it can run automatically when verified coverage falls below a chosen target.

The release note describes a change to an existing security product, rather than a new model or the first launch of CodeRabbit Secure. The useful question is how much work a team needs to repeat after another batch of code lands.

How Delta Deep Scans work

A delta scan revisits changed files and mapped security points whose evidence is stale or incomplete. It preserves the existing map instead of rebuilding the entire baseline.

According to the delta scan documentation, access requires CodeRabbit Cloud, a plan with continuous coverage, repository access and Security write permission. A completed full scan from the previous 30 days is required, along with the minimum coverage shown in the dialog. If more than 40% of included source files have changed, a full scan is needed.

What verified coverage actually measures

The attack surface documentation distinguishes mapped code from code with current verification evidence. Merged changes can make earlier evidence stale. A later review or scan can refresh that evidence.

There is an important denominator here. A map built from reviewed pull requests covers the known reviewed surface. A repository-wide baseline comes from a complete Deep Scan. A 100% figure on the first kind of map does not establish that the whole repository was checked.

For a team deciding when to rescan, that distinction matters more than a green percentage. A target only helps if the mapped scope includes the systems the team expects it to cover.

Automation changes the scanning schedule

GitHub automation checks coverage periodically and attempts a check after default-branch merges. It starts a scan only when the target is missed and scanning and billing requirements are met. A failed merge check can be picked up by a later scheduled check or merge.

Enabling delta automation replaces the repository's existing full-scan schedule. The Security overview confirms that both use the same scheduling slot. Teams should decide how they will refresh the full baseline before switching it on.

Billing still needs room for a full scan

Delta pricing depends on the work performed, including stale or unverified points as well as changed files. Before starting, credits or the monthly limit must cover a full-scan estimate; unused amounts are returned. Paid runs need billing-admin approval.

That creates a practical difference between expected cost and available budget. A small code change may require more billing headroom than its final scan consumes. The documentation does not promise a fixed percentage saving.

The useful shift is making security evidence easier to maintain as software changes. Teams should still watch baseline age, uncovered areas and the quality of findings. Running scans more often is valuable when the evidence becomes more current, not simply because the dashboard refreshes more frequently.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn product updates and complex engineering work into clear stories that developers and founders can understand and share.

Book a 30-minute call