Workflow Instances and Monitoring
What is a workflow instance
Every time a workflow trigger fires, the system creates a new instance (also called a run). An instance is an independent execution of your workflow -- it walks through the steps you defined, in order, against the event or form response that caused the trigger.
You can have many instances of the same workflow running at the same time. Each instance tracks its own progress, status, and timing.
Instance statuses
An instance always has exactly one of seven statuses:
| Status | Meaning | Badge color |
|---|---|---|
| Pending | The instance has been created but has not started executing yet. | Outline (neutral) |
| Running | The instance is currently executing steps. | Green (default) |
| Waiting | The instance is paused on a Wait or Wait Until step and will resume automatically when the delay expires. | Grey (secondary) |
| Completed | All steps have been executed successfully. This is a terminal status. | Green (default) |
| Failed | A step encountered an error and the instance stopped. The failure reason is recorded. | Red (destructive) |
| Cancelled | The instance was manually stopped by a team member. This is a terminal status. | Grey (secondary) |
| Dry Run | The instance was created by a dry-run test. No real actions were executed. This is a terminal status. | Grey (secondary) |
Status flow
Instances move through statuses in a predictable order. Here is how transitions work:
pending --> running --> completed
|
+--> waiting --> running (resumed)
| |
| +--> cancelled
|
+--> failed --> running (retried)
In detail:
- Every instance starts as pending.
- When execution begins, it moves to running.
- If the instance reaches a Wait or Wait Until step, it moves to waiting. When the delay expires (or you manually resume it), it returns to running.
- When all steps complete without error, the instance moves to completed.
- If any step fails, the instance moves to failed. You can retry it, which creates a new attempt starting from running.
- You can cancel a running or waiting instance at any time. This moves it to cancelled.
- Dry-run instances are created with the status Dry Run and never transition to another status.
Available actions per status
Not every action is available on every instance. The table below shows what you can do depending on the current status:
| Action | Available on statuses | Effect |
|---|---|---|
| Cancel | Running, Waiting | Immediately stops the instance. No further steps are executed. The instance moves to Cancelled. |
| Retry | Failed | Restarts execution of the instance. The instance moves back to Running and steps are re-executed. |
| Resume | Waiting | Skips the remaining wait time and continues executing the next step. The instance moves back to Running. |
Actions require edit permissions in your workspace. Viewers (read-only users) do not see the action buttons.
Instance detail view
Click any row in the instance list to open the detail view. You see:
- Instance ID -- the unique identifier for this run.
- Status badge -- the current status with color coding.
- Subject -- the subject type (e.g. Event) and subject ID that triggered this instance.
- Current step -- which step the instance is currently on, or the last step executed.
- Failure reason -- if the instance has failed, the error message is displayed in a dedicated card. This helps you diagnose what went wrong.
From the detail view you can also trigger Cancel, Retry, or Resume actions (depending on the current status).
Use the Back button to return to the workflow detail page.
Dry run
A dry run lets you test your workflow logic without executing real actions. When you trigger a dry run:
- The system creates an instance with status Dry Run.
- Each step is evaluated in sequence -- conditions are checked, but actions like sending emails, updating statuses, or firing webhooks are not actually executed.
- The timeline records what would have happened: which steps ran, what each condition evaluated to, and the simulated duration.
Use dry runs to verify that your conditions branch correctly and that the step order matches your expectations -- before the workflow goes live.
Instance list
Open the Runs tab on a workflow detail page to see all instances for that workflow.
The list shows these columns:
| Column | Description |
|---|---|
| ID | A short identifier for this run, displayed in monospace. Click the row to open the full detail. |
| Status | A color-coded badge showing the current status. |
| Subject | A short identifier of the event or form response that triggered the run. |
| Started at | Timestamp when the instance started executing. |
| Completed at | Timestamp when the instance reached a terminal status (Completed, Failed, or Cancelled). |
The list supports server-side pagination, sorting, and filtering.
Retention: Workflow instances are automatically deleted after 60 days. If you need to keep records longer, export or note the relevant data before the retention window expires.
Workflows in the event detail
You can also view and manage workflow activity directly from an event. Open any event and switch to the Workflows tab. There you see:
- Scheduled -- upcoming workflow runs that have not fired yet. You can cancel them before they execute.
- Active -- instances that are currently running or waiting. You can cancel them if needed.
- Completed -- instances that have already finished running.
This gives you a quick overview of all workflow activity for a specific event without leaving the event detail page. The Workflows tab only appears when your plan includes Workflows.
Related
- Workflows overview -- triggers, steps, and the workflow editor.