Monitoring runs
Every time a trigger fires, GCM creates a workflow run — a single execution attempt for a single subject. The Runs page shows the history, filterable by workflow, status, date, and subject.
Open the runs page
From Workflows → Runs. The default view shows all runs from the last 7 days, sorted by most recent.
Run status
A run can be in one of:
| Status | Meaning |
|---|---|
| Queued | Created, not yet started |
| Running | Actively executing actions |
| Waiting | Paused on a wait_delay, wait_until, or wait_event |
| Completed | All actions finished |
| Failed | An action failed and the run was aborted |
| Cancelled | A human cancelled it |
| Skipped | The trigger fired but a workflow-level filter excluded the subject |
The status updates in near-real-time. Refresh the page or wait a few seconds to see changes.
Filtering
The filter bar lets you narrow by:
- Workflow — one or many
- Status
- Date range
- Subject — a specific member
- Triggered by — manual runs show the admin who started them
URL-encoded filter state means you can share a link to a specific filtered view.
The run detail page
Click any run to see the timeline of action executions. For each step:
- Action name — what ran.
- Started at — when it began.
- Finished at — when it ended (or "Still running…").
- Status — succeeded, failed, skipped.
- Output — the result data the action produced.
- Error message — for failures.
If the run is paused on a delay, the timeline shows the wait step with a "resumes at" timestamp.
Debugging a failure
A failed run usually has one of:
| Error pattern | Likely cause |
|---|---|
Permission denied | The workflow tried to modify a record outside its org or scope. |
Provider returned 4xx | A messaging provider rejected the send (bad number, opt-out, account suspended). |
Merge token resolved to empty | A token referenced a field that's null on the subject. |
Condition evaluation failed | A condition expression had a syntax problem. |
Webhook timeout | An external system didn't respond within the timeout. |
The detail page shows the full error from the action including any provider response code. Click the action node to jump back to the builder and inspect the config.
Retrying
For transient failures (provider 500, network blip), you can retry a failed run from the detail page. The retry starts at the failed action — earlier successful steps are not re-executed.
WARNING
For non-idempotent flows you've already partially completed (e.g. half-sent a message), retrying can produce duplicate side effects. The retry button warns you when the workflow has already side-effected.
Cancelling
A run in Queued, Running, or Waiting status can be cancelled. The action that was about to run is skipped; the run ends in Cancelled status. Subsequent actions don't fire.
Use cancel when you spot a bug mid-deploy and don't want hundreds of wrong messages going out.
Bulk cancel
If you realize a workflow has a bug and 500 runs are in flight, you can bulk-cancel from the workflow's detail page. Cancel all pending runs halts everything for that workflow.
Insights dashboard
The top of the Runs page has aggregate insights:
- Runs in the last 24 hours — total count
- Success rate — completed vs failed
- Average duration — for synchronous runs (excluding delays)
- Top failing actions — which actions fail most often (good for prioritizing fixes)
These tiles are filtered by your top-of-page filter selection.
Permissions
| Action | Admin | Shepherd | Member |
|---|---|---|---|
| View runs list | yes | scoped to unit | no |
| View run detail | yes | scoped | no |
| Retry a failed run | yes | no | no |
| Cancel a run | yes | no | no |
Shepherds see runs for members in their scope — useful when they want to confirm "did the newcomer get the welcome message" without admin access.
Retention
Run history is kept for 90 days. Older runs are purged nightly. The aggregate stats (counts of runs, success rate) are kept indefinitely so reports stay accurate, but the per-step detail goes away.
TIP
If you need long-term audit of workflow effects, the side effects themselves (messages, member updates) are kept in their respective logs (communication log, activity log). The 90-day limit is just for the workflow run plumbing.
Common questions
Why is my run stuck in "Waiting"? Check the active step — it's almost always a wait_delay or wait_event. The detail page shows when it will resume.
Why are runs for one workflow much slower than another? Usually because the workflow has slow actions (external webhooks, large segment loops). The duration breakdown on the run detail page shows which step is taking longest.
Can I see runs for a deleted workflow? Yes — deleted workflows stay in the runs filter (greyed out). Historical runs are kept for 90 days regardless of workflow deletion.
Next steps
- Visual builder — fix issues you find here.
- Multi-step & delays — understand the waiting states.
- Actions — debug action-specific failures.