Skip to content
ScrinCloudScrinCloud Docs

Troubleshoot ScrinOps

Start with the latest visible product state. Do not retry blindly, copy raw provider data into support channels, or bypass scope, evidence, entitlement, approval, or Git controls.

Typical time
10–30 minutes
You need
The selected scope and safe request reference
Outcome
A bounded next action or an honest runtime blocker

Step 1: Identify the failing stage

Section titled “Step 1: Identify the failing stage”
Symptom Check first Safe next action
ScrinOps navigation missing Environment capability and plan Ask an administrator to confirm rollout
Setup options unavailable Existing project/workspace access Retry after scope is available
Health degraded or revoked Cloud connection status Repair the existing connection
Discovery returns no sources Provider read permissions and region Correct least-privilege access
Dry preview blocked Required scope and readable sources Resolve the stated readiness gap
Incident list empty Project/workspace and filters Confirm live ingestion separately
Partial connector data Evidence or work-item degradation Continue only with visible data
Start diagnosis disabled Evidence state and expiry Refresh or collect eligible evidence
Run deferred Capacity Leave the accepted run queued
Run rejected Scope, policy, plan, and evidence Correct the gate; do not bypass it
Activity unavailable Authoritative run refresh Retry bounded readback
Remediation review unavailable Link scope and reviewer role Reopen from the owning project
Synthetic ScrinOps connection health stage showing a healthy status and Check health and Discover sources actions.
Troubleshooting 1 of 3 · Locate the failing stageA synthetic connection-health stage with clear safe actions for checking health and discovering sources.

Step 2: Preserve safe evidence

Section titled “Step 2: Preserve safe evidence”

Record only:

  • the product area and action label;
  • selected provider and environment without account identifiers;
  • safe status or error code;
  • approximate time and browser-visible request reference;
  • whether the action was read-only, queued, or terminal; and
  • whether any temporary resource or external notification was created.

Never include credentials, tokens, cookies, authorization headers, raw alerts, raw logs, evidence bodies, full digests, provider account/subscription IDs, object locations, repository content, reviewer identities, or internal runner details.

Synthetic ScrinOps lifecycle audit showing a created incident summary, safe evidence manifest, and status update.
Troubleshooting 2 of 3 · Capture a safe support summaryA synthetic bounded lifecycle audit with safe event labels and approximate recorded times.

Step 3: Retry only when state changed

Section titled “Step 3: Retry only when state changed”
  • Retry Check health after repairing connection access.
  • Retry Discover sources after permission or region changes.
  • Run a new dry preview after the selection changes.
  • Refresh an incident after evidence collection changes.
  • Retry diagnosis as a new run only from an eligible terminal state.
  • Retry remediation review after its snapshot refresh finishes.

Repeated submissions do not make an unavailable runtime healthy and can create confusing duplicate attempts.

Step 4: Separate proof levels

Section titled “Step 4: Separate proof levels”
Synthetic ScrinOps diagnosis activity with completed safe lifecycle steps and no raw provider logs.
Troubleshooting 3 of 3 · Report the verified proof levelSynthetic backend-sanitized diagnosis activity demonstrating authorized runtime evidence without raw provider output.

Report status precisely:

  • Source present: the UI/API/control code exists.
  • CI green: automated checks passed for a commit.
  • Deployment wired: Terraform or workflow configuration includes the component.
  • Runtime proven: an authorized environment returned the expected safe result with cleanup evidence.

Do not collapse these into one claim.

Check your result

Section titled “Check your result”

You have either corrected the specific prerequisite and observed a new authoritative result, or documented an honest blocker with safe evidence and no unverified success claim.

Common blockers

Section titled “Common blockers”
  • Feature disabled: requires an environment rollout decision.
  • Contract unavailable: requires the owning runtime/API deployment, not more browser retries.
  • Scope denied: requires correct tenant/project/workspace access.
  • Evidence expired: requires newly collected authorized evidence.
  • Runner capacity exhausted: wait for the accepted run or administrator action.
  • Git protection blocks progress: resolve checks or reviewer requirements in Git; do not weaken them from ScrinOps.

When runtime evidence is missing, say so. Source documentation can guide the journey but cannot prove incident ingestion, diagnosis, evidence retention, notification, remediation, merge, apply, or deployment.