Scan failures and blocked pages

Before retrying a failed scan

Use this page when a scan run fails, a page is skipped, a public page cannot be fetched or browser rendering fails. The scan run owns the first decision because it stores the accepted scope, page-level reason fields, retry timing and report evidence handoff.

• Open the scan run
• Review `blocked_reason`, `skipped_url`, `page_status`, `robots.txt` and browser evidence before changing scope.
• Keep private, unsupported, third-party and unapproved pages blocked.

Triage the scan run

Follow the path `Dashboard → Shortcut paths → Get the first useful report → Scans → Scan to report path → Failed page reason → Scope check → Retry, evidence review or stop`.

1. Open `/dashboard`, choose Get the first useful report or open `/scans`, then choose the failed scan from Scan to report path. Result: `scan_run_id`, `scan_status`, selected plan and accepted scope are visible before any retry.
2. Read `blocked_reason`, `skipped_url`, `page_status`, `robots.txt` and `browser_error_code` for each failed page. Result: WebRiskOps separates scope blocks, fetch blocks and browser-rendering failures.
3. Compare every `skipped_url` with the accepted scope on `/projects/{project}` and the stored `accepted_scope_url` list. Result: pages outside approved scope stay excluded.
4. If `SCAN_SCOPE_BLOCKED` appears, return to `/projects/{project}` and read Shortest path to first useful report before changing selected groups, manual URLs or path rules. Result: scope changes are explicit, same-domain, customer-authorized and stored before the next scan.
5. If `PAGE_FETCH_BLOCKED` appears, check HTTP status, redirects, robots rules, WAF or anti-abuse messages. Result: unreachable pages are retried only after the public page is available.
6. If `SCAN_BROWSER_RENDER_FAILED` appears, check console/network evidence and `render_error` before retrying. Result: render-only failures do not change accepted scope.
7. If `SCAN_PRIVATE_ROUTE_BLOCKED` or `SCAN_UNSUPPORTED_TARGET` appears, stop the scan path. Result: login-only, private, third-party or unsupported targets do not become manual delivery work.
8. Press retry from `/scans/{scanRun}/retry` only after the owning reason is cleared and `scan_retry_after` has passed. Result: cooldown and provider limits are respected.
9. Open `/reports/{report}` after a successful retry and verify `screenshot_path` or evidence availability. Result: missing evidence continues to Missing evidence instead of hiding the scan failure.
10. Continue to Resolve blocked or failed states, Missing evidence, Provider connection errors or Self-hosted connectivity when the block owner is no longer the scan run. Result: the customer lands on the guide that owns the next action.

Blocked page reasons

Use the reason code to decide whether to retry, change accepted scope or stop.

• `SCAN_SCOPE_BLOCKED` means the page is outside accepted scope, outside allowed paths, excluded by a path rule or not customer-authorized.
• `PAGE_FETCH_BLOCKED` means the public page was unavailable, redirected unexpectedly, blocked by robots rules, denied by WAF or returned a fetch status the scanner cannot use.
• `SCAN_BROWSER_RENDER_FAILED` means the fetch may have worked, but the browser could not render enough page state for evidence.
• `SCAN_RATE_LIMITED` means the scanner must wait for `scan_retry_after` before another attempt.
• `SCAN_PRIVATE_ROUTE_BLOCKED` and `SCAN_UNSUPPORTED_TARGET` mean the target cannot be scanned through the public-page workflow.

Safe scope changes

Change accepted scope only from the project surface and only when the page is safe to include.

• Use `/projects/{project}` to update selected groups, manual URLs, include paths, exclude paths and scope acceptance.
• Add a URL only when it is same-domain, public, customer-authorized and inside the selected plan limits.
• Remove URLs when they redirect to private areas, admin paths, checkout account pages, third-party hosts or unsupported file/download targets.
• Keep `robots.txt`, anti-abuse blocks, login walls and provider policy blocks visible instead of bypassing them.

Ready and blocked scan states

A scan is ready to retry only when the reason is clear and the owning product state has changed.

• Ready: accepted scope updated, public page restored, redirect fixed, robots rule changed by the customer, WAF block removed, render error corrected or retry cooldown expired.
• Still blocked: page outside accepted scope, private route, unsupported target, missing ownership proof, active anti-abuse block, private-network dependency, exhausted retry cooldown or plan limit conflict.
• Evidence follow-up: a successful retry can still expose missing `screenshot_path`, HTML snapshot or issue evidence, which belongs to the Missing evidence guide.

Continue after scan triage

Use the linked guide for the owner that remains after scan-run triage.

• Resolve blocked or failed states explains how to find the owning workflow when the scan run is only one part of the blocked state.
• Missing evidence explains missing screenshots, HTML snapshots and report artifacts after the scan finishes.
• Accepted scan scope and Manual URLs and path rules explain safe project-scope changes before a retry.
• Data collected and excluded explains why private pages, secrets, account-only content and out-of-scope data stay excluded.
• Provider connection errors and Self-hosted connectivity explain blocks caused by provider access, base URLs, allowlists or private-network constraints.