A run is stuck or failed

Symptom

A run stays queued or in progress longer than expected, finishes as failed, or shows no report after you expected work to complete.

Quick checks

• Refresh the run or Activity view and confirm its current state.
• Check whether another run for the same repository and action is active.
• Confirm repository access and the current provider target.
• Open the latest available report or history; an older completed report can remain visible while new work runs.

Diagnose the cause

A queued run may be waiting for execution capacity or another conflicting action. A running audit or improvement can spend time on repository setup, tools, bounded verification, or report preparation. Auto-pentest may also encounter target access barriers. Do not infer failure from duration alone, but do not start duplicate work to “unstick” it.

A failed state should preserve the useful domain reason: repository unavailable, invalid or missing source context, provider authorization, environment or package-manager setup, target unavailable, verification failed, or report generation failure. Distinguish a valid issue-only or no-action outcome from infrastructure failure.

Resolve the problem

Wait for an active run to reach a terminal state before retrying the same action. Restore provider access or required target consent when the report names that blocker. If verification failed, fix the documented environment or repository baseline rather than broadening the runbook. Retry report or summary generation only after the source reports are present and valid.

Escalate safely

Provide project, repository, action name, visible run ID if shown, start time, last state, expected commit, and redacted error text. Do not include tokens, credentials, raw secret findings, or destructive test payloads. If a task continues running after its state is clearly stale, support can inspect execution history without you creating duplicate provider artifacts.