The Activity Log allows you to track past workflow executions. It includes information on triggered workflows, single-step executions, and events received that did not trigger a workflow.
Overview
In the Activity Log, you can display the response JSON of each workflow run by clicking the drop-down arrow in the workflow's row. The response JSON depends on the activity type (all, workflow_runs, step_executions, etc.).
Activity Logs can also be collected and passed to third parties, such as Elasticsearch or AWS. See the template for creating a nested workflow to collect Activity Logs or Audit Logs.
Use the search bar in the Activity Log page for free-text searches inside the event JSONs.
Understand workflow statuses
The workflow status represents the status of the current or most recent workflow execution. They are displayed in the status column of the Activity Log page.
Status | Description |
| The workflow execution was completed successfully. |
| A step failed, causing the workflow to fail. Hover over the information icon to see the name of the step that failed. View the Run Log to get more information about the failed step. |
| The workflow is currently running. |
| The workflow was manually stopped. |
| There are a few reasons a workflow might be on hold:
|
| The maximum number of concurrent workflow runs (workflows in Running status) was reached. |
| A workflow that was queued for 24 hours will be dropped. |
Scenario IDs
Scenario IDs identify the specific types of events that generate records in Activity Logs.
A number of these scenarios can also trigger workflows in Torq. When you create a workflow with a Torq Cases or System Events trigger, you select a scenario to trigger the workflow execution.
The following scenarios are recorded in Activity Logs:
System events
Scenario ID | Event |
| A publish review is requested for a workflow |
| A remote runner reports a health status change |
| A request to share a workflow is created |
| A Socrates runbook execution completes |
| A Socrates runbook execution begins |
| A step within a workflow fails |
| A variable value is updated |
| A workflow execution fails |
| A workflow is published |
| A workflow is unpublished |
Cases events
Scenario | Event |
| An associated observable is linked to a case |
| An associated observable is unlinked from a case |
| An attachment is added to a case |
| The access policy on a case changes |
| Access permissions on a case change |
| The assignee on a case changes |
| The category of a case changes |
| A new case is created |
| A case is deleted |
| An event attached to a case is updated |
| The review conclusion on a case changes |
| A reviewer is assigned or changed on a case |
| The severity level of a case changes |
| The state/status of a case changes (e.g., Open to Closed) |
| Tags on a case are added or removed |
| A case is updated (general catch-all) |
| A bulk action is performed across multiple cases |
| A comment is added to a case |
| A custom field value on a case changes |
| A link on a case is updated |
| A case note is updated |
| An observable is added to a case |
| An observable is removed from a case |
| An observable on a case is updated |
| A user is @mentioned in a case |
Troubleshooting
Resend workflow events
Only events that triggered workflow executions that ended can be resent. This feature does not support step execution.
You can resend events that triggered workflow executions to recover from multiple simultaneous workflow execution failures. This includes workflows that ended with a status of Success, Failed, Stopped, or Dropped.
To resend events:
Open the Activity Log: Navigate to Monitor > Activity Log.
Select events: Select at least one event based on the workflow Status. Only events that triggered workflows that ended are eligible.
(Optional) Review the events: Open the dropdown listing the selected events, and click Deselect to remove any irrelevant events.
Resend events: Click the Resend events button and then Resend to confirm.
A confirmation message will be displayed at the bottom indicating a successful, partially successful, or failed status.
Add missing webhook trigger events to workflows
When a webhook-triggered workflow is unpublished, events can be missing from the Activity Log of a nested, duplicate, or new workflow using the same trigger. This is likely because the webhook trigger uses an asynchronous or synchronous URL that is attached to the main workflow.
To add the missing events, make sure the main workflow is disabled but published so the events can still be seen. Then, copy the events and paste them in the additional workflow to use them in a Test Run input event.
Use a template to collect Torq Activity Logs
Torq’s Gather Torq Activity Logs template creates a nested workflow that gathers a workspace's Audit or Activity Logs and returns the logs to the parent workflow. After importing the template to your workspace and customizing it as necessary, call it within a parent workflow. The nested workflow will return a JSON array of the requested logs from within the desired timeframe.



