Inspect runs and recover failures
Read automation state, isolate the failed stage, and retry work without losing successful outputs.
Every automation run is a production record. It connects the input, node sequence, stage state, generated projects, outputs, and failures for one execution.
Read the run before retrying it
Open the automation and select the relevant run. Identify:
- which trigger started it
- which input or workspace object it processed
- the last successful node
- the node that failed or was cancelled
- which outputs already completed
- whether the connector still has access
Fix the cause before retrying. Repeating the same request with the same invalid input usually produces the same failure.
Common recovery paths
| Failure | Check | Recovery |
|---|---|---|
| Source file was skipped | File type, folder path, and subfolder rules | Move or replace the file, then start a new run. |
| Connector lost access | Account authorization and folder permissions | Reauthenticate, then retry supported work. |
| Model preparation failed | Source geometry, format, and processing state | Correct the model and upload it again. |
| Template stage failed | Template availability, version, and required views | Repair or republish the template, then retry. |
| Render capture failed | Capture status and project state | Retry supported failed work. Completed captures can remain available. |
| AI stage failed | Prompt, source image, reference inputs, and service state | Reduce the request or retry the failed variant. |
| Export failed | Destination access, folder existence, and provider state | Restore access, then retry delivery. |
Cancel intentionally
Cancel a run when its source, template, or requested output is wrong and further work would waste production capacity. Cancellation does not mean every already-completed artifact is deleted.
Prevent duplicate work
For API-driven production, use an idempotency key on supported writes. A retry with the same key can return the existing operation instead of creating another object.
Folder and event automations should still be designed to tolerate repeated source events. Use stable naming, inspect the run record, and verify destination state before starting a manual replacement.
Know the delivery boundary
Signed webhooks report supported state changes, but current delivery does not provide a durable exactly-once guarantee. Webhook consumers should:
- verify the signature
- acknowledge quickly
- tolerate duplicate events
- retrieve the current object state from the API
- run a reconciliation check when an event may have been missed
Success state
A recovered run is complete when the intended outputs exist, their destination is verified, and the run history explains any skipped or replaced work.