Resolve common workflow failures

Step timed out

Symptom: The step exceeded its configured timeout duration.

Resolution:

• Check the step's Settings tab to see the current timeout value. Increase the timeout if the step needs more time to complete.
• Alternatively, investigate why the external service or script is taking longer than expected.

Retry attempts exhausted

Symptom: The step failed and exhausted all retry attempts.

Resolution: In the activity list, review the step with its current retry count. Check the error details to understand the persistent failure.

Upstream step produced unexpected output

Symptom: A step failed because it received data in an unexpected format from an upstream step.

Resolution: Click the failed step and check the Parameters pane. Then click the upstream step and check its Output pane to compare the data.

External service returned an error

Symptom: An HTTP request step or Ansible Automation Platform step fails with an error response from an external service.

Resolution: HTTP request steps and Ansible Automation Platform steps depend on external services. Check the Output pane for the response status code and body. Common causes include authentication failures, network issues, and service outages.

Expression evaluation failed

Symptom: A step that uses template expressions, such as ${node_id.field_name}, fails if the referenced field does not exist in the upstream output.

Resolution: Verify that the upstream step completed successfully and produced the expected output fields.

Script output truncated

Symptom: The script step produced more than 1 MB of stdout or stderr output. The workflow engine truncates each stream at 1 MB and writes a message to stderr, such as [Output truncated: exceeded 1048576 byte limit]. If the combined output exceeds the platform payload limit, a second message appears: [Payload truncated: serialized activity result exceeded Temporal payload limit].

Resolution: Reduce the volume of data the script writes to stdout or stderr. Filter or summarize data within the script so that only the relevant output is written to stdout.

Integration credential misconfigured

Symptom: The workflow failed when the run started because a large language model (LLM) or Model Context Protocol (MCP) integration credential is missing, disabled, or deleted. Automation orchestrator validates all integration credentials before execution begins.

Resolution:

1. Navigate to Configuration > Integrations and verify that the integration shows an Available status.
2. Navigate to Configuration > Credentials and confirm that the credential is enabled and belongs to the correct project.
3. Open the workflow in the builder and verify each task agent step's credential configuration.

LLM provider unreachable during execution

Symptom: A Task Agent step failed because the LLM provider was unreachable during a live workflow run. The integration can show Available status in Configuration > Integrations while the provider experiences transient connectivity issues. The background health check and the execution-time LLM call are independent paths.

Automation orchestrator automatically retries transient LLM failures (such as rate limits, timeouts, connection errors, and server errors) with exponential backoff before marking the step as failed. By default, the agent orchestrator retries up to 3 times after the initial attempt (4 total attempts). The workflow engine does not retry Task Agent steps at the Temporal activity level. Authentication errors and invalid request errors fail immediately without retries.

When retries are exhausted, the Task Agent step transitions to Failed with an error message that identifies the failure type. The workflow outcome depends on the step's on-failure setting:

• Stop workflow or branch on failure (default): The workflow transitions to Failed after all reachable steps complete.
• Continue on failure: The workflow completes with a Completed with errors status and downstream steps still execute.

Resolution: To distinguish an LLM connectivity failure from other Task Agent step failures, click the failed step. Review the error details in the execution failure view. LLM connectivity errors report a connection or timeout error. Other Task Agent failures, such as response schema validation errors or tool execution errors, report a different error type.

To resolve this failure:

1. Check the LLM provider's status page for ongoing outages or rate limit events.
2. Navigate to Configuration > Integrations, click the integration name, click Edit integration, then click Test connection to verify that the provider is reachable.
3. If the provider is healthy, verify that the API key has not been revoked or rotated at the provider.
4. After the provider issue is resolved, retry the workflow run.

Resolve the failure and retry the run

Symptom: Workflow run fails for various reasons, such as step configuration, service outage, and incorrect input data.

Resolution: Identify and address the root cause, then retry the run:

• If step configuration caused the failure, fix the configuration in the builder and run the workflow again.
• If a transient issue such as a service outage caused the failure, retry the execution. You can click Retry run from the execution detail view, the options menu on the Workflow Runs page, or the builder run history.
• If incorrect input data caused the failure, update the trigger data or mock data and start a new run.