Scan depth

Every connected repository has a scan depth. It decides how hard each scan looks, and it is the trade you control between speed, cost, and exhaustiveness.

The two depths

Max depth is a plan entitlement

Setting a repository to max on a plan that does not include it is refused with depth_unavailable rather than accepted and quietly ignored, so nobody chooses a depth they will never get. On Pro and Max there is no cap on how many max-depth scans you run: what binds is the organization's allowance, which a max scan spends faster. See Usage and limits.

Every repository starts at default

Setting it

cf settings
cf settings depth
cf settings depth max
cf settings depth default

cf settings depth with no argument asks; with one, it sets it. cf settings on its own prints the depth the repository is on now. The same control is in the workspace, under Scanning in the repository's settings. Either way the change applies from the next scan: it does not re-run anything on its own.

What it costs

A max scan of the same repository takes several times longer than a default scan and does more analysis, so it spends several times as much of the organization's allowance. Depth multiplies work on the code analysis; the deterministic checks (dependencies, secrets, configuration) produce the same results at either depth.

Depth, triggers, and checks are separate

Depth says how hard a scan looks. Triggers say when a scan starts. Checks say which analyses run. All three are per repository, and any combination is valid: a scheduled weekly max scan with every check on is a reasonable audit posture, and push-triggered default scans with the default checks is the everyday one.