When a Torq workflow fails or behaves unexpectedly, the fastest path to resolution is to start with the most granular execution evidence and work outward. This guide walks through a structured troubleshooting approach, from step-level logs to workspace-wide monitoring, recovery, and escalation.

For most issues, start with the step's Execution Log. It provides the most granular evidence for what happened during a run, including both standalone step executions and step executions that occur as part of a full run.

When a step fails, Torq displays the status code, error reason, and suggested solution. Step execution history is retained for 30 days.

Tip: If the error isn’t immediately clear, use the Torq Knowledge Base or chatbot to map the message to the next troubleshooting step.

The Step Execution Log includes Input, Output, and Debug tabs. Review them in this order:

After you identify the failing step, use the Run Log in the workflow designer to review the execution end-to-end. Run Log helps you confirm:

Go to Monitor → Activity Log when you need a workspace-wide view of what happened and when you want ongoing monitoring across workflow runs. Activity Log is especially useful to:

Activity Log tracks:

Activity Log is also where Torq supports recovery actions at scale. Torq allows you to resend events that triggered workflow executions to recover from multiple simultaneous failures.

Resend applies to workflows that ended with Success, Failed, Stopped, or Dropped, and it does not support step execution.

Use troubleshooting as a checkpoint to confirm failure detection is configured, so similar issues are surfaced earlier.

Torq supports workflow-level failure notifications configured per workflow. These notify you when a published workflow fails and are typically used for ownership-based alerting (for example, notifying the team responsible for that workflow).

Torq also provides System Events for workspace-wide monitoring. System Events can trigger workflows when platform-level events occur, including:

System Events are commonly used to build centralized monitoring, escalation, or reporting that reacts automatically to failures across multiple workflows.

Together, these options allow you to:

Use the following checks when the issue points to a specific failure category.

If the issue appears to be invalid JSON, validate it using a third-party visual editor or validator.

Ensure any tool you use is approved for your environment, and avoid sharing sensitive or production data. Sanitize payloads before testing.

If multiple users update workflows in your workspace, review Version History to identify recent changes and correlate them with when failures started.

Some failures are not caused by workflow logic or configuration. Errors related to execution environment, connectivity, or resource availability may indicate a Step Runner issue.

For these cases, refer to the Troubleshoot Self-hosted Step Runners article.