Skip to content

When a scan fails

A failed scan tells you why it failed, in plain language, on the report page. This page explains what each reason means and what to do about it.

The most important thing to know up front: a scan that failed for a reason outside your control does not cost you a scan credit. Vortex classifies every failure and offers a free re-run where the cause was on the target’s side or ours.

What the report saysWhat it meansWhose sideRe-run free?
The target is rate-limiting our scanner (HTTP 429)Your host or CDN started refusing requests because they arrived too quicklyNeither, really — see belowYes
The target returned a server error (HTTP 5xx) when we tried to reach itThe site was erroring when we reached itTargetYes
We could not connect to the target URLWe couldn’t establish a connection at all — DNS, a closed port, or a network blockTargetYes
The target refused our scanner (HTTP 401/403/407)A firewall, WAF, or IP allowlist rejected us outrightTarget — needs a config changeNo
The target returned an unexpected responseSomething answered, but not in a way the scan could proceed fromUsually a wrong URLNo
Authentication failedThe test user couldn’t sign in — changed credentials, a new login form, MFAYour configurationNo

The split is deliberate: the first three are transient or ours to fix, so retrying costs nothing. The last three need you to change something first, so a re-run draws a credit like any other scan — retrying without fixing the cause would just fail again at your expense.

This one is worth explaining properly, because it’s the least intuitive and the most common.

Your site was working correctly. A host that refuses a burst of rapid requests is doing its job. What went wrong is that our scanner sent requests faster than your host was willing to accept.

Vortex now paces itself to avoid this — see how fast Vortex scans. It opens slowly against a site it hasn’t scanned before, speeds up only while the site is comfortably keeping up, and slows down on its own when it isn’t. It also remembers the rate your site tolerated and opens there next time.

That handles most limiters, but not all. If you keep hitting 429s:

  • Exempt our scanner IPs from the limiter for the duration of a scan — see scanner IP addresses.
  • Run a Quick scan, which targets a lower rate than the deeper intensities.
  • If your limiter has a very low threshold (a few requests per second), tell us — we can advise on the right intensity for it.

”We could not connect” but the site loads in my browser

Section titled “”We could not connect” but the site loads in my browser”

This pairing is common and almost always means an IP restriction. Your browser comes from your own address, which your firewall already allows; our scanner does not. Add our scanner IP addresses to the allowlist and re-run.

The same applies to staging and pre-production sites restricted to an office IP range — a very frequent cause.

A failed report shows a Retry scan button. When the failure qualifies for a free re-run, the button says so explicitly and the note under it explains why the re-run costs nothing.

Two limits apply:

  • Up to 2 free re-runs per original failed scan. Beyond that, a re-run is a normal scan and draws a credit — at that point the failure is persistent and worth investigating rather than retrying.
  • Welcome scans are counted separately. If your first scan during onboarding failed, it did not use up your welcome scan; you can retry it free from the report page. An organization gets up to 3 welcome-scan attempts in total.

Send us the report link and the failure message. The failure reason and its classification are recorded with the report, so we can see exactly what the scanner saw without asking you to reproduce anything.