What each scan depth does
Quick, Standard and Deep differ by two numbers. This page reads both of them from the same table the API applies when it freezes a scope snapshot, so it is not a separate description that could drift from the behaviour.
| Depth | Crawl depth (levels from the starting URL) | Page cap (pages the crawl may reach) | What that means |
|---|---|---|---|
| Quick | 0The starting URL only. A link found on it is not followed. That is not nothing β an authorisation resolves to one starting URL, that URL is still requested in full, and so a Quick scan crawls exactly one page. | 25 | A single pass over the one starting URL this asset resolves to. Enough to confirm the target is reachable and that the authorisation and the outbound path work end to end. Not enough to conclude anything about a site as a whole. The page cap on this row is a ceiling the crawl will not cross rather than a count of pages this depth reaches: with one URL to start from and no link followed, Quick stops at one page well below it. |
| Standard | 3 | 500 | A walk of the site 3 levels away from the starting URL. This is what the request form selects for you, and it is the depth to choose unless you know why you want another. |
| Deep | 10 | 5,000 | The widest crawl this platform will run. It is also the budget every scan other than Quick used before the depths were separated, so choosing it skips nothing that used to run. |
There is a limitation behind the table above, and it is the one to read before choosing Quick. A depth sets the crawl budget and nothing else: choosing a shallower one removes no check at all. What runs is decided elsewhere β by the techniques your signed authorisation permits, which every detector is checked against before it is allowed to start, and by the detector itself, since some are assessed once per origin, such as the TLS assessment and the page capture, rather than once per page. So Quick is not a lighter examination of one page. It applies to that page the same checks Deep would. Fewer pages is the only lever a depth gives you, and that is a recorded gap rather than a design decision.
The two numbers are frozen when the scan is accepted
Choosing a depth writes these numbers into the scope snapshot at the moment the scan is accepted, and the scan reads that frozen copy for the whole of its life rather than looking the depth up again while it runs. What follows from that: changing your mind means requesting another scan rather than adjusting this one, and a scan already under way keeps the budget it was accepted with.
A depth narrows the authorisation. It never widens it.
The signed authorisation is the ceiling β which hosts, which paths, and how many requests per second. A depth only decides how much of that ceiling to use, and no value on this page reaches a page the authorisation does not already cover. The scan plane and the outbound traffic control each check the same thing again, independently, and each one fails closed.
A retest is created from findings rather than from an asset, which is why the request form on an asset page does not offer it. The route that would create one does not exist yet, and no scan has ever carried a parent scan id, so nothing in this product can produce a retest today.
POST /scans/{id}/retest
Its entry in the same budget table is deliberately not a cheaper one: 10 levels and 5,000 pages, which is exactly Deep. A retest has to be able to reach whatever the scan it retests reached. Inheriting the scope of that earlier scan is the right answer, and it needs the route to exist first.
None of this is a promise about how long a scan takes
The API does return an estimated duration for each depth. It is a fixed constant chosen when the field was added, not a measurement, and no finished scan has ever been timed against it. Treat it as a placeholder: do not plan a maintenance window around it, and do not quote it to anyone.