Prerequisites
You needstates.view to investigate states and logs, and states.retry to request a retry. Access to the workflow editor is also needed to inspect its diagram.
Find the item
Open States, set the date range, and choose Search. Use the column filters for trace ID, status, initial workflow, or batch name. Open the matching state to inspect its current workflow and trace logs.
The trace view includes logs and can open the relevant workflow on the diagram. Use it to identify the failed step and its input context before changing configuration or requesting another execution.
Fix the cause first
Check the error against the step’s input, mapper, global variables, and target-system response. Typical causes include missing metadata, an unexpected file format, unavailable credentials, or a receiving service rejecting the operation. Keep the trace ID, batch name, workflow, time, and error when escalating. Include only the metadata needed to reproduce the failure.Choose a recovery action
The Rerun page accepts trace IDs and can load failed states by batch name. Only failed states are accepted for retry.
When saved failed-step information exists, the second option supplies that step and its recorded data to the retry. Without that information, do not assume earlier steps will be skipped.
Executions that recorded a published version are normally retried against that version. If recovery depends on changed workflow logic, inspect the recorded version and confirm the recovery path before repeating the request; a newly published definition may not be used by the retry.
After recovery, return to States, check for a completed result, inspect the trace, and verify that the expected destination record exists without unintended duplicates.
Where to read next
API clients and service accounts
Create a dedicated machine identity, grant its group access, rotate its secret, and disable an integration.