Troubleshooting checklist

Start with the latest visible product state and the exact action that needs attention. Do not retry blindly or widen access just to see whether the result changes.

Before you begin

Record:

• the product page;
• the exact action label;
• the selected organization, project, workspace, and environment using safe display names only;
• the visible status or message;
• the approximate time, including time zone; and
• the browser-visible request identifier, if one is shown.

Do not open developer tools or copy detailed technical responses into a support request.

Step 1: Confirm the selected scope

Many apparent failures are scope mismatches.

1. Confirm the signed-in account.
2. Confirm the organization.
3. Confirm the project and workspace.
4. Confirm the environment, cloud provider, and region.
5. Confirm the selected diagram, Terraform revision, run, discovery result, incident, or cost period.
6. Return to the owning page if you opened the item from a bookmark or shared link.

If the selected scope is wrong, correct it before changing access or retrying.

Step 2: Read the complete user-facing state

Capture the title, status, short explanation, and suggested action.

Visible state	Meaning	Normal next step
Not configured	Required setup has not been completed	Complete the named setup
Unavailable	A capability, dependency, or permission is not ready	Check the stated prerequisite
Pending or queued	Work was accepted but has not started	Wait and refresh within the product
Deferred	Work is waiting for capacity or another safe condition	Leave it accepted; do not duplicate it
Running	Work is still active	Monitor the existing run
Partial	Some scope completed and some needs review	Inspect incomplete items separately
Failed	The attempt reached a terminal problem	Correct the stated cause before retrying
Cancelled	The attempt stopped without completing	Start a new attempt only if still needed
Timed out	Completion was not confirmed within the allowed period	Check final status before retrying
Expired or stale	Evidence or access is no longer current	Refresh or collect new evidence
Unsupported	The product cannot handle the item through that workflow	Keep it separate and request guidance
Unknown	The product cannot make a trustworthy claim	Gather stronger evidence; do not assume success

Do not treat a missing status as success.

Step 3: Check your access

Ask which boundary owns the action:

• Account: sign-in and security settings.
• Organization: shared plan, policy, and organization membership.
• Project: viewing, editing, review, or administration.
• Workspace: environment and delivery scope.
• Cloud or Git connection: approved external access.
• Reviewer group or approval role: review authority.
• Plan: feature availability and limits.

If your role is too limited, ask the project or organization owner for the smallest appropriate change. Do not request broad administration or provider access when a focused project role is enough.

Step 4: Check connections and readiness

When the workflow depends on a cloud or Git connection:

1. Open the relevant connection page.
2. Confirm the intended connection and owner.
3. Review health, verification, environment, region, and scope.
4. Use the product’s test or refresh action once.
5. Correct only the permission or scope named by the result.
6. Return to the original workflow and refresh it.

Do not paste credentials into notes, comments, screenshots, or support requests.

Step 5: Check policy, approval, and plan limits

An action may be healthy but intentionally blocked.

• Review policy findings and required fixes.
• Check whether an exception is allowed and who must review it.
• Confirm the approval gate and minimum reviewers.
• Confirm that approvals are current for the exact revision or plan.
• Review the organization plan and current usage limits.
• Confirm that the selected environment permits the requested action.

Never bypass a warning, reviewer requirement, or approval gate to test whether the action works.

Step 6: Refresh safely

Use the page’s Refresh, Check health, Test connection, or equivalent action when available.

• Refresh the existing item before creating a replacement.
• Wait for active work to reach a terminal state.
• Retry only after scope, access, configuration, or evidence changed.
• Submit once, then follow the accepted item.
• If the browser disconnected, reopen the owning page and inspect current status before starting again.

Repeated clicks can create duplicate requests and make the timeline harder to understand.

Step 7: Isolate the symptom

Use the narrowest reproducible path:

1. Return to the owning page.
2. Select the same safe scope.
3. repeat only the action that failed;
4. note what you expected;
5. note what appeared instead; and
6. confirm whether the problem happens in another supported browser or private browsing window when organization policy allows it.

Do not clear useful saved work, delete resources, disconnect accounts, or revoke team access solely as a troubleshooting experiment.

Step 8: Check common product areas

Area	Check first
Sign-in or verification	Newest message, correct account, allowed verification method
Team access	Selected project, invitation status, member role, reviewer group
Architecture Studio	Selected diagram, unsaved changes, required properties, supported relationships
Validation	Exact finding, affected resource, current diagram revision
Cloud Discovery	Connection health, provider, region, selected scope, unsupported results
Terraform editor	Workspace, file, unsaved changes, active revision, visible diagnostics
Terraform run	Existing run status, plan evidence, policy findings, approvals
Cloud Cost	Linked account, billing scope, period, freshness, unknown or unallocated cost
ScrinOps	Availability, incident scope, evidence eligibility, diagnosis status
Billing	Organization, plan, seat count, renewal state, usage limit

Step 9: Prepare a safe escalation

If the problem remains, include:

• page and action label;
• expected and actual result;
• approximate time and time zone;
• safe organization/project/workspace display names;
• provider and environment without account identifiers;
• visible status or error code;
• request identifier;
• whether the action was submitted once or retried;
• whether any temporary item was created; and
• the troubleshooting steps already completed.

Do not include passwords, one-time codes, recovery codes, credentials, Terraform state, private links, raw provider data, customer data, or unrelated people and resources.

Use Get help for the full support template and screenshot rules.

Check your result

Troubleshooting is complete when one of these is true:

• the named prerequisite was corrected and the product shows a new authoritative result;
• the action is intentionally blocked and the correct owner or reviewer has the next step;
• the work remains active and you are monitoring the existing item; or
• a safe support request records the exact unresolved symptom without claiming success.