# Errors, retries and support

Canonical: https://savrn.com/cloud/docs/platform-errors-support

SAVRN Cloud · Coming soon. Public documentation and a browser simulation are available; connected services are not yet available.

A useful failure report identifies the action, expected result and state that actually remained in the SAVRN Cloud workspace. This guide connects local troubleshooting with the request identifiers, bounded retries and retained evidence that connected services will need for reliable recovery.

**SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments**

## Diagnose the local workflow

Start with the message beside the field or action. Required fields, numeric bounds and unavailable transitions should explain what needs correction. Preserve your input while fixing it. A disabled action can indicate that a prerequisite record or lifecycle state is missing.

Check the selected project, model and related resource before repeating an operation. For a deployment problem, inspect [Deployments](https://savrn.com/cloud/console/#/deployments) and [Operations](https://savrn.com/cloud/console/#/operations). Operations offers **Run demo readiness checks** and synthetic incident actions **Create incident**, **Acknowledge** and **Resolve**. For an experiment problem, inspect its detail in [Evaluations](https://savrn.com/cloud/console/#/evaluations) or [Training](https://savrn.com/cloud/console/#/training). A browser refresh reloads local state; it does not contact a worker.

## Report a useful issue

Record the screen, action, visible state, expected result and whether the problem repeats. Use synthetic examples. Include a local record identifier where available, but never paste a real secret into a report. An export can demonstrate the state if its simulation metadata remains intact.

The application does not provide a production support desk or service-level commitment.

## Before connected services launch

Publish stable error codes, request identifiers and retry semantics. Distinguish rejected-before-execution, failed-during-execution and unknown-outcome cases. Retrying an uncertain charged operation must not silently create duplicate work. Durable jobs need bounded retries and reconciliation. Operators need redacted diagnostics and ownership of escalation; customers need a clear next action, impact statement and incident channel. Verify recovery through retained effects, not a success toast alone.