Troubleshooting

Scan didn’t trigger

Work through these in order. The first match is almost always the cause:

• Draft PR. Draft pull requests are skipped until they’re marked ready for review. Switching draft → ready emits a ready_for_review event that triggers a scan.
• Outside the auto-review allowlist.Settings > Repositories controls which repos auto-review runs against. If the list is non-empty and your repo isn’t on it, the webhook is acknowledged but no scan starts.
• Own-PR-only is enabled. When that filter is on, PRs by authors other than your connected GitHub username are skipped.
• PR was ignored. @infiniview ignore stores a per-installation skip for that repo and PR number. Re-enable from the dashboard or trigger a manual scan from Reviews.
• Push debounce window. A synchronize event inside the configured debounce window is coalesced. Either wait for the window to elapse or kick a manual scan.
• GitHub App not installed on the repo. The OAuth handshake from Settings only lets the dashboard list repos. PR scans also need the GitHub App installed on the repo or org.

Scan is stuck queued

The Reviews list shows a queued status and the run never starts. Common causes:

• Plan limits reached. Concurrent scan limits depend on plan tier — see Billing & plans. Older runs finish or fail out before the queue advances.
• Account capability not enabled. Some scanners and runtime agents are gated by account-level capabilities. Disabled tools show up in the Trust panel after the run starts; nothing about queuing itself blocks here.
• Brief platform queue. If a scan stays queued for more than 10 minutes with no upstream cause, post in the dashboard support channel with the review ID.

Scan finished degraded

A degraded result means findings are valid but coverage was reduced. The Trust panel attributes each gap to a typed reason — work through them in this order:

1. scanner_skipped— a scanner exited early or wasn’t applicable. Check that the scanner is enabled (Security > Scanners) and that the repo has files it can analyze.
2. runtime_not_tested — runtime testing didn’t reach this surface. Most commonly, the app didn’t build, the entrypoint wasn’t served, or a required credential wasn’t set. Add missing values to repo secrets.
3. replay_unavailable — a runtime finding fired but the replay couldn’t be persisted. Re-run with evidence_detail: full for richer artifacts.
4. degraded — a generic coverage warning. Skim recommendations in Trust, then rerun from review detail.

Scan finished blocked

blocked means the pipeline stopped before scanning. Today the most common cause is Unsupported App: the repository isn’t a browser-based web app the sandbox can build and serve. The PR check completes neutrally rather than returning a misleading pass.

• Web apps with a non-default port: add a .infiniview.yml override or environment variables that document the entry command.
• API-only and library repositories: scans persist static and dependency evidence; runtime testing is intentionally skipped.
• Build prerequisites missing: ensure standard manifests (package.json, pyproject.toml, Gemfile, etc.) and any private dependencies’ credentials are present in repo secrets.

Scan failed

failedmeans the pipeline couldn’t complete. The run records the error class in the timeline. Typical recoveries:

• GitHub access lost — the OAuth or App install was revoked mid-run. Reconnect from Settings, then rerun.
• Repository moved or deleted— fetch returns 404. Update the review’s repo reference or open a new review.
• Snapshot validation — the merged .infiniview.yml failed validation. Run POST /api/validate-infiniview-yml against the file to see the exact error.
• Time budget exhausted — the wall-clock cap kicked in. Trim exclude_paths, lower max_plans, or split monorepo scans across paths.

Repository not visible in the launcher

• You haven’t connected GitHub.Settings > GitHub starts the OAuth handshake.
• The repo is in an org you don’t have repo:read on. The dashboard shows what your token can list.
• Pagination. /api/github/repos returns a page of results — use the ?q= filter or scroll to load more.

Expected findings are missing

• Severity threshold. Anything below the configured threshold is dropped before persistence. Lower it temporarily to inspect.
• Exclude paths or rules. Check the active snapshot — the frozen merge of dashboard config and .infiniview.yml. Excluded paths and rules don’t emit findings.
• Active suppressions.Findings matching an active fingerprint suppression are hidden. Findings > suppression filter surfaces them; deleting a suppression restores presentation without touching history.
• Scanner skipped. If the relevant scanner appears in the Trust panel as scanner_skipped, no rules from it ran on this surface.

Rerun is disabled

The rerun affordance only appears when readiness checks pass. The readiness panel calls out exactly what’s blocking — pick the matching cause:

• GitHub access not reachable — reconnect the GitHub OAuth, reinstall the GitHub App, or restore repo access.
• Required env signal absent — a previous run flagged a missing variable; add it via repo secrets.
• Unsupported app type — runtime testing can’t be replayed; static-only rerun is still available via the API.
• Replay prerequisite missing — usually a previously confirmed exploit lost its artifact. Run a manual scan instead to rebuild from scratch.

@infiniview commands are ignored

Only trusted authors can run commands: owners, members, or collaborators on the repository, or users with write, maintain, or admin permission. Comments from anyone else are silently ignored.

• Bot accounts and outside drive-by reviewers won’t pass the trust check.
• Forked-PR comments require the commenter to have permission on the upstream repo, not the fork.
• Re-check that the comment body uses one of the documented commands exactly (@infiniview review, @infiniview ignore, @infiniview help). Anything else is treated as conversation.

Secrets aren’t reaching the sandbox

• Secrets are scoped per repository. A value set against org/foo isn’t visible to scans of org/bar.
• The listing endpoint returns only key names — verify the key string matches exactly what the app expects (case-sensitive).
• Values are decrypted server-side only when injected into the sandbox at scan time. If a value looks malformed, delete and re-add it.
• If the value is required by the build, runtime, and a runtime agent (e.g., third-party API key), the missing-env-signal flag will appear on Trust. Resolve before rerunning.

Live progress stream stalls

The run detail page connects to /api/scan-runs/{id}/live (Server-Sent Events). If the panel stops updating:

• Some corporate proxies buffer SSE — open the page in a network that allows long-lived connections.
• The dashboard falls back to /api/scan-runs/{id}/progress for one-shot polls if the stream drops.
• Closing the tab does not cancel the run. Reopen from Reviews to reattach.

CSV download is unavailable

GET /api/scan-runs/{id}/csv requires a terminal status (completed, degraded, blocked, or failed). Active runs return 409 Conflict. Use the backlog export at /api/security-findings/export if you need a cross-run dump instead.

Still stuck

• Capture the review ID and scan run ID (visible at /runs/{id}).
• Open the Trust panel and Recommendations — copy the typed gap codes into your support thread.
• Drop the question into the in-app feedback widget. Common questions also have short answers in the Operator FAQ.