Failed or cancelled scans: what to check and how to re-run

A failed or cancelled scan in Cyberlop is a scan run that ended before the Reporting phase finished, and you can still use what it found. Open it from Recent Scans, read the red Scan failed banner, check the Findings and Sitemap counts for partial results, fix the likely cause from the checklist below, then click Scan to run the same profile again.

What do Completed, Failed and Cancelled mean?

Every scan ends with one of three results: Completed, Failed or Cancelled. They show as green, red and grey badges in the Result column of Recent Scans, and as a status badge on the scan's own page.

A scan is one run of a scan profile. It moves through five phases: pre-recon, recon, vulnerability analysis, exploitation and reporting. You can switch exploitation off in the profile. A run that stops part-way through leaves whatever the earlier phases produced.

What is the difference between failed and cancelled?

Failed means the platform could not finish the scan. Cancelled means a person chose to stop it. The Activity feed, an audit log, records a cancellation as Cancel · Scan with the person's email as the actor, so you can see who stopped a run and when.

How do you find a failed or cancelled scan?

You can find a failed or cancelled scan in three places: Recent Scans, the Recent scans table on the Dashboard, or the Activity feed. Recent Scans is the best starting point because it shows the target, profile, who ran it, location, result and both times.

1. Click Recent Scans in the sidebar.
2. Type a target or profile name in Search scans by target or profile... if the list is long.
3. Look at the Result column for a red Failed or grey Cancelled badge.
4. Compare Initiated and Finished. Two identical times mean the scan ended within the same minute.
5. Click anywhere on the row except the buttons to open the scan page.

The Dashboard shows the same result in its Recent scans table, with the cost column showing a dash when a scan has no cost. Its Running scans card counts scans still in progress, so a failed scan is not counted there.

What does the Scan failed banner say?

The banner reads Scan failed and then: "The scan could not be completed. Please try again, or contact your administrator if the problem persists." It appears at the top of the scan page for failed scans only. It does not name a cause, so the checklist further down is how you narrow one down.

Below the banner the page still has its usual header, with Refresh and Download report, the status and trigger badges, and the four tabs: Overview, Findings, Sitemap and Diff. The scan detail page guide explains every field.

Overview fields worth reading first

On the Overview tab, the Run details card shows Status, Trigger, Location, Cost, Profile, Started, Finished and, for white-box scans, Commit.

• Location tells you whether the scan ran in the Cyberlop cloud or on one of your own scan agents.
• Trigger tells you whether it was a manual run, a schedule or your CI pipeline.
• Commit shows which code the scan read, so you can check it used the branch you meant.
• Profile links to the profile, which is where most fixes happen.

When should you click Refresh?

Click Refresh if a scan still looks like it is running after you expected it to stop, or if you are not sure the page is current. The API describes the matching endpoint as syncing the scan status from the workflow. A typical scan of a small app takes roughly an hour.

Can you use findings from a failed scan?

Yes. A failed scan can still hold the findings and discovered endpoints found before it stopped, and they show as counts on the tabs, for example Findings (43) and Sitemap (34). Treat them as real but incomplete.

1. Open the Findings tab and click a row to open the issue dialog. The Evidence tab shows the request, response and reproduction steps for anything the scan proved.
2. Triage the findings as normal (finding triage): set a Disposition and Assignee, then click Update status. See triage findings.
3. Open the Sitemap tab to see which hosts and endpoints the scan reached. Missing areas show where test coverage stopped.
4. Use Download report if you need a PDF. The menu offers Open issues only, Include fixed & accepted and Fixed issues only. The Report button on the Recent Scans row appears on completed scans only.

Why did my scan fail? A troubleshooting checklist

The banner gives no cause, so work through the checks below from the cheapest to the slowest. Each one is something the app shows you or lets an admin verify. Only the platform administrator can read the raw workflow log.

Checks before anything else

Repository and Git token

White-box scans clone the latest code from the repository at launch. Public repositories clone as they are. Private ones need a personal token in My Account or an organisation token in Settings → Git Access, and the token is sent only to the allowed hosts listed there. A token for the wrong host, or one that has expired, is a common reason a launch fails. Follow connect a repository and Git access to check it.

Ownership of a black-box target

Black-box scans need proof that you own the target, by a DNS TXT record or approval from Cyberlop staff. If the card is not showing Verified, ask an admin to complete it. See verify target ownership. Scan only applications you own or have permission to test.

Scan agent status

A scan agent connects out to Cyberlop over HTTPS and only needs outbound port 443 to the app. An agent that stops sending heartbeats shows as offline. If you revoke an agent, its profiles go back to the Cyberlop cloud, which cannot reach a private network, so a scan of an internal app can then fail to reach its target. Read self-hosted scan agents.

Checks when the scan ran for a while first

• Is your own app up? A staging environment that has just redeployed, scaled to zero or moved behind a firewall can drop requests part-way through. Check it in a browser first, and prefer a proper test environment for scans.
• Is your app rate limiting the scanner? A server may answer with 429 Too Many Requests (RFC 6585) or 503 Service Unavailable (RFC 9110). Ask your team to allow the scan location, or choose a quieter environment. See API rate limiting.
• Do the logins still work? A rotated password, a replaced TOTP secret or an expired token means the scan cannot reach pages behind login, which defeats authenticated testing. Check the role chips on the Sitemap, then update the role in the profile. See authentication roles and form login.
• Did the scan stop at the exploitation phase? That phase uses a real browser against the live target. A profile with it switched off tests the code only. See the exploitation phase.

Do AI limits make a scan fail?

Not by design. Rate limits slow a scan down but do not fail it, because the agents wait and retry. When the included allowance runs out, scans on Cyberlop AI pause until next month, and connecting your own provider credential in Settings → AI Provider keeps them going. Your plan decides the limits, and they are shown in Settings → Plan & usage. One caution from the same page: a subscription-style OAuth token can hit throttling part-way through, so the agents cover less of the codebase. Use an API key for the best coverage. See AI provider settings.

How do you cancel a scan, and what happens to it?

A person whose role includes the scan:cancel permission can cancel a scan while it is running. The API exposes this as POST /api/scans/:id/cancel. The result badge then reads Cancelled and the Activity feed records Cancel · Scan. If you cannot find or use the control, ask an admin to cancel it for you or to adjust your role.

Cancel a scan when you started it against the wrong profile, the wrong environment or an app that is mid-release. Once cancelled, open the scan page and check the Findings and Sitemap counts, as you would for a failed scan, and treat any results as partial.

Should you delete a failed scan?

Only to tidy the list. Delete this scan removes the run and keeps the target's findings, but a support conversation goes faster with the scan still there. Deleting the target also removes its profiles, schedules, scans and findings.

How do you re-run a failed or cancelled scan?

To re-run a scan, fix the likely cause first, then click Scan on the scan's row in Recent Scans, or on the profile or target row. It runs the same profile again as a new scan with its own ID.

1. Note the target, profile, Started time and the 8-character scan ID from the scan page subtitle.
2. Work through the checklist and fix one thing at a time.
3. If you changed the profile, Preview YAML and Save first. See edit a scan profile. You cannot edit a target: to change one, delete and recreate it.
4. Click Scan. The scan starts at once and is durable, so you can leave the page.
5. Open it from Recent Scans and watch the phase, cost and counters, then click Refresh if the page looks stale.
6. When it completes, open Diff to see New, Fixed and Regressed findings against the previous completed scan.

A white-box re-run clones the repository again, so the Commit on the new scan may differ from the failed one.

Failed scans from schedules and CI

Scheduled and CI runs fail the same way and appear in the same list, with their trigger shown on the scan page. The CI snippets are non-blocking: the job polls for the result up to 120 times, every 30 seconds, prints the findings and never fails your build. A failed scan will therefore not turn your pipeline red, so look at Recent Scans, or turn on the When a scan I started finishes email in My Account. See CI/CD integration and schedule scans.

When should you contact your administrator?

Contact your administrator if the same scan fails twice after you have worked through the checklist. Send them the target name, profile name, scan ID, start time and what you already checked. They can look at settings you may not see, and the platform administrator can read the workflow log.

Next step: once a scan has completed, check what it reached in the scan sitemap, and see retesting for why running the exploit again proves a fix.