Triage a scan that failed or completed partially

A scan health value of Error or Partially (completed) means the reported results are incomplete. Determine the coverage consequence before deciding whether to rescan.

1. Select the scan row with a health value of Error or Partially (completed).
2. Determine the coverage consequence from Reference C: Scan health values. For Partially (completed), at least one scanner did not complete, and the results for that scanner category are absent rather than empty.
3. Treat every enabled scanner on the repository as unverified for this scan. Do not attempt to identify the failed scanner from Findings By Type. A scanner that completed and detected nothing contributes no entry to the breakdown, and a scanner that failed contributes no entry either — the breakdown reports detections, not execution, and cannot distinguish the two cases.
4. Diagnose the underlying cause. Follow Diagnose a scan failure through data source instance health, which reports errors per repository with a specific error type. The error type identifies what to correct; a rescan repeats the failure when the cause is a revoked token, a missing permission, or a webhook subscription error.
5. Trigger a rescan once the cause is corrected, or immediately if the diagnosis indicates a transient failure. The Rescan action triggers a new scan for the same repository and branch, and is available only when the scan health is Error or Partially (completed). The Rescan action is not available for a scan with a health value of Completed or In Progress.

   • From the inventory: Right-click the periodic scan row and select Rescan
   • From the side panel: Select the periodic scan row to open the side panel, then select Rescan next to the Scan Health property on the Overview tab
6. Verify recovery. Confirm that the scan health of the repository resolves to Completed. A health value of Completed is the only signal that every enabled scanner executed, and is therefore the only evidence that the coverage gap closed. A rescan that returns Error or Partially (completed) again indicates that the underlying cause persists — return to step 4 rather than repeating the rescan.

Important: Treat a Partially (completed) result as unknown coverage for every enabled scanner on the repository, not as a clean result for any of them. A repository reporting zero secrets because the Secrets scanner failed is indistinguishable, in the scan results alone, from a repository with no secrets. Restore the scan to Completed before drawing any conclusion from the reported counts.

Caution: A repository that returns to Error on every cycle silently consumes the 12-hour cadence without producing coverage. Escalate a repeatedly failing repository to the owner of the VCS integration rather than allowing the failure to persist across cycles. Identify a repeatedly failing repository with the unscanned repositories endpoint (GET /public_api/appsec/v1/scans/unscanned-repositories), which returns the repositories not successfully scanned within a specified number of days — a repository returned with days set to two or more has failed across consecutive cycles. The scan inventory presents individual scan results and does not aggregate failures across cycles, so recurring failure cannot be detected from the inventory alone. See Public APIs for scan management.

Note: Escalation is performed outside Cortex Cloud. The scan inventory carries no owner, assignee, or acknowledgement field, and triggering a rescan requires the Application Security Periodic View/Edit permission that a governance user may not hold. Record the handoff in the tracking system your organization uses, and verify closure by confirming that the scan health of the repository reaches Completed on a subsequent cycle.