Errors, retries and support

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 and 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 or 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.