Skip to main content
Find your symptom below. Each entry gives the cause, what to check, and the fix, with a link to the page that covers it in full.

​
Start here

​
Domain and setup

Cause: the TXT record doesn’t match what CloudThinker expects, or DNS hasn’t updated yet.Check: compare your published record with the DNS record name and TXT value under Target ownership. A common cause is a provider that appends the zone name, so the domain appears twice in the record name.Fix: remove the duplicate suffix, wait a few minutes, and click Check again. See Verify the domain.
Cause: the app’s domain isn’t verified yet, or the TXT check failed.Check: open the app’s Target ownership card. Users who aren’t workspace admins see Ask a workspace admin to verify instead of the DNS proof.Fix: finish the DNS proof and click Check again, then reopen Run pentest. If you aren’t a workspace admin, ask one to verify it from Cyber → Settings or the app’s Target ownership card. See Run a pentest.

​
Test logins

A password login is saved without signing in, so saving it doesn’t prove it works. The run signs in when it starts. A session token is different: Verify and attach saves it only if the request succeeds, and Run pentest tests it again before each run. A Long-lived token isn’t checked first, so a token your app rejects doesn’t stop the run: it keeps going and its report lists what it couldn’t test. See Add test users.
Cause: a test user’s password login didn’t sign in. A run with a failed required login stops instead of testing as a logged-out visitor.Check: the username, password and Login URL in the app’s Settings under Test identities. The Login URL must be on the same origin as the app’s target and inside its scope.Fix: update the login and run again. For a login that needs MFA or sits on a separate identity provider domain, use a Session token instead. See Cyber quickstart.
Cause: the saved session token expired or the target now rejects it. The run dialog tests session tokens before launch.Check: the alert in the Run pentest dialog. Login verification unavailable means the check couldn’t reach the target, not that the login was rejected.Fix: click Update login to paste a fresh cURL request, or Test again after fixing the account. The run can’t start until the token works. See Deep dive pentest.

​
CAPTCHA logins

Saving a password test user never signs in, so only form problems show up when you click Save login. The CAPTCHA, timeout and MFA messages below come from the login step of a run. See Handle CAPTCHA logins.
Cause: the challenge wasn’t solved.Check: that your test keys or bypass header are installed on the target, and whether automated fallback is allowed for that test user.Fix: install matching test keys or a bypass, or allow fallback if the solver is on for your CloudThinker. If none of that works, attach a Session token. See Pick an approach.
Cause: CAPTCHA solver enabled is off for your whole CloudThinker, or it has no AI vision model to call. Allow for this identity can’t override that.Check: with CloudThinker support, or whoever runs CloudThinker for your company, whether the solver is on.Fix: have the solver turned on, or switch to Target test keys or Bypass header. See What automated fallback can handle.
Cause: the challenge type is one the run can’t handle.Check: which provider and challenge your login page shows.Fix: use a target bypass or a Session token. See Handle CAPTCHA logins.
Cause: the login redirected outside the app’s target or scope.Check: Login URL (optional) and the app’s target and scope.Fix: point Login URL at a page on the target’s origin, or widen the scope to cover the login path. For a login on another domain, use a Session token. See Configure the login.
Cause: your widget and server don’t use matching test keys for the provider you selected.Check: that the sitekey in your login widget and the test secret in your server-side verifier belong to the same test pair. Entering a sitekey in CloudThinker doesn’t change your server’s verifier.Fix: install the matching pair on staging. A test sitekey can’t pass production verification. See Provider test keys.
Cause: the header name is reserved or isn’t a valid header name, or you tried to save a header bypass from the form.Check: the name isn’t one of Authorization, Proxy-Authorization, Cookie, Host, Content-Length, Transfer-Encoding, Connection, Upgrade, TE, Trailer, Origin or Referer.Fix: pick a name only your bypass uses, such as X-QA-Bypass. Save the test user with None, then set the header through chat. See Set Customer bypass.
Cause: the login, including any CAPTCHA attempt, ran past the login deadline (60 seconds by default).Check: whether the run spent the time on a CAPTCHA challenge.Fix: retry, or ask CloudThinker support, or whoever runs CloudThinker for your company, to raise the password login deadline. A test key or bypass header avoids the solver time entirely. See Configure the login.
Cause: the password form isn’t the last step of your login.Check: sign in by hand and note any step after the password.Fix: attach a Session token copied from a signed-in browser. See Add test users.

​
Runs and coverage

Cause: a check needed something you didn’t provide: a second role, a tenant, a repository, or API docs.Check: click Show limited checks on Start, or read the run’s Report tab.Fix: add the missing input and rerun. Limited checks aren’t passed checks. See Run a pentest.
Cause: Changes only compares against the last successful run, and there isn’t one yet.Check: the app’s Runs tab for a successful Whole codebase run.Fix: complete one Whole codebase run first. See Run now or on a schedule.
Cause: Deep dive is turned off for your whole CloudThinker. It isn’t tied to your plan.Check: whether the other intensity cards can be selected.Fix: choose Full for destructive testing. To get Deep dive turned on, ask CloudThinker support, or whoever runs CloudThinker for your company. See Deep dive pentest.
Cause: you entered a credit limit. Credit limits apply to manual runs only.Check: the Credit limit · Optional field in the run dialog.Fix: clear the field to schedule. See Deep dive pentest.
Cause: expected. The limit stops new passes at 90%, but the pass in progress and the report still finish.Check: the credits each completed pass used, in the run’s activity feed.Fix: set a lower limit next time if you need more headroom. See Deep dive pentest.

​
Findings

Cause: the board refuses some moves. Dismissed never accepts a drag because a dismissal needs a reason. Needs verification only takes back its own cards. A fix proved by a scan only moves when a scan reopens it.Check: the reason the board shows when it refuses the drop.Fix: to dismiss, open the finding and give a reason. Otherwise move the card to a column that accepts it. See Triage findings.
Cause: you have the Viewer role.Check: your role in Roles.Fix: ask a workspace admin for the Developer role. You can still copy and download findings.
Cause: a dismissed finding leaves the work columns.Check: the All tab, which includes Dismissed findings.Fix: open the finding and click Reopen finding, or drag its card from Dismissed onto a work column. CloudThinker includes it in scans again. See Triage findings.
Cause: a later scan proved the problem again.Check: the app’s Runs link to see which run reopened it.Fix: open the finding for the new evidence and fix it again. See Triage findings.
Cause: flagging a finding for retest doesn’t start a scan.Check: whether a schedule is enabled in the app’s Settings.Fix: click Run pentest in the app header, or enable a schedule. See Triage findings.

​
Code Audit

Cause: no branch has been audited yet and your role can’t start one, or Code Audit is turned off for your whole CloudThinker.Check: your role in Roles. Viewers can read audits and findings; only Admins and Developers can start one.Fix: ask an Admin or Developer to run the branch’s first audit. If nobody sees Repositories, ask CloudThinker support, or whoever runs CloudThinker for your company, to turn Code Audit on.
Cause: that repository isn’t connected, or the connection doesn’t cover it.Check: the Git provider in More → Workspace settings → Connections.Fix: connect or widen access to the repository, then reopen Audit repository. Review setup and Code Audit access are separate, so a repository configured for Review doesn’t open a different one here. See Connections.
Cause: a branch keeps the findings its last completed audit published. A failed attempt never replaces them.Check: the failed attempt on the branch for its error.Fix: fix the cause and click Run audit again. See Track a branch.
Cause: verification is pending, blocked, or inconclusive for that finding.Check: its evidence and the audit’s limitations.Fix: treat it as unresolved and look at it yourself. A finished audit with blocked verification is not a clean result. See Read the results.
Cause: every audit describes the commit it pinned, and nothing rewrites it later.Check: the commit on the finding against the commit that carries your fix.Fix: click Run audit, or wait for the branch’s next scheduled audit. See Schedule reassessment.
Cause: auditing on every push uses the repository’s Review connection, and that repository isn’t connected or enabled in Review.Check: the repository named in the message, in Review → Settings.Fix: connect or enable it there, then return to Schedule branch checks and save. Your choices in the dialog are kept. See Review setup.
Cause: the branch’s dependency files aren’t supported or aren’t resolved, or library checking is off for your CloudThinker.Check: the inventory’s Complete extraction or Incomplete extraction label on the branch.Fix: run an audit on a branch with resolved dependency files. If Libraries never appears, ask CloudThinker support, or whoever runs CloudThinker for your company. See Monitor library vulnerabilities.

​
Reports

Cause: no finding is selected, more than 200 are selected, or an export is already preparing.Check: the selection count.Fix: select between 1 and 200 findings. See Cyber reports.
Cause: a selected finding changed since you picked it. The export stops instead of dropping it silently.Check: the selected findings. Your selection is kept.Fix: review the selection and click Export PDF again. See Cyber reports.
Cause: you don’t have Chat access. The tooltip reads “Chat access is required for Custom reports.”Check: hover the option to read the tooltip.Fix: ask a workspace admin for Chat access. See Cyber reports.
Cause: there’s no reference report.Check: Report preferences for a saved reference. Files must be PDF or DOCX, up to 5 MB.Fix: add a reference report, or save one in Report preferences. See Cyber reports.
Cause: the report is written when the run finishes. A stopped run doesn’t produce one, and a failed run that ends before writing it shows the same message.Check: the run’s status on the Runs tab.Fix: start a new run to get a report. See Cyber reports.
Cause: each run keeps the preferences from when it started.Check: when the run started compared with when you saved the preferences.Fix: use Revise report to change an existing report, or start a new run. See Cyber reports.

​
Next steps

Cyber quickstart

Run a scoped Safe pentest against a staging app

Run a pentest

Test users, scope, intensity, and schedules

Run a Code Audit

Audit a repository branch and follow it across commits