Scan timed out

The page has a deeply nested DOM

A page renders an unusually large or deeply nested DOM, so parsing and analysing it runs past the per-page budget.

47%

of cases

How to fix

Pages built from large component trees — endless lists, heavy dashboards, or deeply nested layouts — take longer to render and parse. When one page exceeds its budget, Wolfix marks it timed out and moves on.

To get a clean run:

1. Point the scan at a representative public page (your landing or marketing page) rather than a data-heavy app view behind auth.
2. If a specific route is the problem, check for runaway client-side rendering — virtualise long lists or paginate large tables.
3. Re-run the scan. A quick scan inspects fewer pages than a deep scan, so it's a fast way to confirm the rest of the report is healthy.

The crawl hit a rate limit at high concurrency

When many scans run at once, the shared browser-crawl backend throttles requests and a page fetch is dropped before it returns.

31%

of cases

How to fix

Wolfix's dynamic crawl runs through a managed headless-browser backend. During high-concurrency bursts — for example many scheduled scans firing together — that backend can rate-limit a request, which surfaces as a per-page timeout.

To fix:

1. Re-run the scan a few minutes later; transient rate limits clear quickly.
2. If you trigger many scans on a schedule, stagger their start times rather than firing them in one batch.
3. If timeouts persist across retries, it's not your project — open a ticket and include the scan ID so the team can check backend capacity.

The scan hit the function ceiling

A single scan step ran past the platform's serverless function limit. This is rare — the production tier allows 60 seconds per step.

22%

of cases

How to fix

Each scan step runs inside a serverless function with a hard time ceiling. On the production tier that's 60 seconds per step, which is comfortable for almost every project — so this cause is rare and usually points at an unusually heavy single page rather than a misconfiguration on your side.

To fix:

1. Narrow the scan target to the specific URL that's timing out, then re-run so the step has its full budget for one page.
2. Use a quick scan to confirm the rest of the report completes — it does less work per step than a deep scan.
3. If a single normal-sized page still exceeds the ceiling on retry, open a ticket with the scan ID so the team can inspect the trace.