Most scan issues fall into one of four buckets: authentication drift, scope misalignment, rate-limit friction, and sandbox isolation quirks. This page walks through the symptom, the usual cause, and the fix for each.
Scan stops at login#
Symptom. The scan status page shows reconnaissance completing but deeper testing never starts. The scan finishes with zero findings and a “no authenticated session” warning.
Cause. The auth profile referenced by the target no longer produces a valid session. The common triggers are an expired OAuth client secret, a rotated API key, or an OAuth-issued session that the identity provider has invalidated.
Fix. Re-validate the auth profile from the workspace settings page with the “Test sign-in” button. If the test fails, regenerate the credential and update the auth profile. Every scan that queues after the update will pick up the new credential.
Scan overruns its time budget#
Symptom. The scan runs past its configured max_duration and is killed by the scheduler, producing a partial report.
Cause. Scope inflation. Either the target’s include list matches more paths than expected, or the run is walking an unexpectedly large surface. The scan status page’s “paths observed” counter is the easiest signal.
Fix. Tighten the include list to the routes you want scanned and move anything that only needs periodic coverage onto a separate scheduled target. Raise max_duration only after scope is honest.
Rate-limit hits in the target#
Symptom. The scan report shows HTTP 429 responses from the target and missing findings on endpoints that returned them.
Cause. The workspace-level default rate limit is higher than the target’s actual capacity. This is more common on staging targets that share infrastructure with another environment.
Fix. Override rate_limit on the target with a lower rps. Start at half the default and adjust upward once scans complete cleanly. The Authorization Matrix honours the same rate limit as the underlying scan.
Sandbox PoC fails to publish#
Symptom. A Critical or High finding that should have produced a Sandbox PoC instead shows “sandbox unavailable.”
Cause. The sandbox image is missing the runtime required to reproduce the exploit (usually an RCE or finding that targets a language runtime the default image does not carry).
Fix. The finding is still reported with its captured request/response evidence. If you need the sandbox reproduction for a specific runtime, contact support — bespoke runtimes are provisioned on request for enterprise workspaces.
When the fix is not here#
Every pentest ships with a log bundle. Attach it to a support ticket and we usually respond within one business day with the next diagnostic step or a fix.