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 |
Troubleshooting 1 of 3 · Screenshot placeholder
Locate the failing stage
Show a synthetic ScrinOps flow with one highlighted failure at availability, setup, incident, diagnosis, run, or remediation review.
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.
Troubleshooting 2 of 3 · Screenshot placeholder
Capture a safe support summary
Show a fictional support template containing stage, safe status, environment, time, and cleanup state.
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”Troubleshooting 3 of 3 · Screenshot placeholder
Report the verified proof level
Show four synthetic levels: source present, CI green, deployed wiring, and authorized runtime evidence.
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.