Set scan scope and run live audits

Before starting a live audit

A live audit is the automated browser run that turns accepted project scope into scan evidence. It should use the stored accepted boundary, not a fresh guess at every discovered URL. Use this page after the project has domain authorization, plan or credit readiness and [Accepted scan scope](/docs/projects/accepted-scan-scope). If any of those gates is missing, fix that state before starting the scanner.

Start from the accepted scope

Follow the path `Projects → Project detail → Scan scope selection → Scope acceptance → On-demand risk scan`.

1. Open /projects and choose the project that shows Scope accepted. Result: the project detail page keeps the accepted domain, selected URL groups, manual URLs and plan limits visible before the scan action.
2. Review Scan scope selection before starting the run. Result: only public same-domain selected groups and manual URLs are live-audit input.
3. Check On-demand risk scan for Ready, Scope limits and Crawl limits. Result: you know whether billing, plan allowance, accepted scope and crawler safety allow the run.
4. Click Run scan once. Result: WebRiskOps queues one live audit for the accepted boundary and prevents duplicate worker demand for the same project.
5. Open Open latest scan or /scans/{scanRun}. Result: the scan detail page shows queued, running or completed state, current page and artifacts.
6. Wait for Completed before opening the report path. Result: screenshots, HTML snapshots, console and network evidence and skipped-page reasons can be tied to the accepted scope.

Watch live audit status

Use `/scans/{scanRun}` when you need the run state, worker progress, current page, queue timing and artifact links.

• Queued or running status means the scanner has accepted the job or is collecting browser evidence. Wait for the current run instead of starting another scan.
• Completed status means the run has terminal evidence for report generation or review.
• Active scan means another queued or running scan already exists for the project. Open that scan instead of creating a duplicate run.
• Plan required means open [Billing](/billing), resolve the automated plan or credit blocker and return to the project after billing state is ready.

Understand skipped or failed pages

Skipped and failed states should explain what happened without asking the customer to guess.

• Skipped outside scope means the page was not inside the accepted domain, selected URL groups, manual URLs or path rules.
• Scanner failed means the run could not collect enough evidence. Retry only after the failure reason says the target is reachable and scope is still correct.
• Rendering blocked means browser rendering could not observe the page reliably. Use [Browser rendering](/docs/projects/browser-rendering) before retrying.
• Evidence incomplete means read the available screenshots, HTML snapshots and console/network evidence before deciding whether to retry or continue.

Continue to crawler evidence

When the live audit is running, use the scan detail page until the run reaches a terminal state. If it completes cleanly, continue to [Read your first report](/docs/getting-started/read-first-report). If the run skips pages or behaves differently than expected, continue to [Crawler behavior](/docs/projects/crawler-behavior), [Browser rendering](/docs/projects/browser-rendering) or [Failure and skipped-page meanings](/docs/projects/failure-and-skipped-page-meanings) based on the state shown by the product.