Skip to main content
Start with the failing boundary, not a reinstall.

​
First five checks

  1. Record the exact workflow revision, execution ID, node, and time.
  2. Decide whether the failure happened during validation, queueing, input resolution, node execution, or evidence retention.
  3. Read the stable error code and redacted resolved input before changing configuration.
  4. Check only the boundary involved: connection, path, domain, browser profile, runner compatibility, or service status.
  5. Reproduce with the smallest safe test and preserve the original failed execution.

Desktop

Startup, local data, runner, update, and workflow validation.

Browser

Engine health, profiles, locators, navigation, and artifacts.

Runner

Pairing, compatibility, signatures, environment, leases, and capacity.

Permissions

Revision approval, path, domain, profile, command, connection, and workspace authorization.

Report an app bug

Send structured product feedback directly to the sndbox maintainers.

Diagnostics and support

Share redacted aggregate diagnostics only through an approved, time-boxed grant.
For API errors, record the HTTP status, stable error.code, and correlationId. For a run, record workflow revision, execution ID, failing node, attempt, and the redacted evidence already shown in the inspector.

​
Symptom to evidence

​
Preserve a useful report

Include steps to reproduce, expected and observed results, app and runner versions, target environment, and the smallest redacted evidence that demonstrates the failure. Never paste access tokens, cookies, connection secrets, protected variables, raw customer data, or an entire unreviewed trace into an issue. If the outcome of a send, command, upload, delete, or other mutation is uncertain, stop automatic retries and inspect the destination first. Troubleshooting should not create a second incident.