The Sim trigger runs a workflow when events happen in your workspace: another workflow's run fails or succeeds, a workflow is deployed, or an alert condition like a latency spike or cost threshold is met. Use it to build side-effect workflows — alerting, escalation, auto-remediation — composed from any blocks (Slack, email, webhooks, custom logic).
Events
Pick one event per Sim trigger block:
Plain events — fire on every occurrence:
- Execution Error: a watched workflow's run failed
- Execution Success: a watched workflow's run completed successfully
- Workflow Deployed: a watched workflow was deployed (including redeploys and version rollbacks)
Alert conditions — evaluated as runs complete (failure-based conditions evaluate on failed runs), with a cooldown so they fire at most once per cooldown window:
- Consecutive Failures: the last N runs all failed
- Failure Rate: failure rate meets or exceeds a percentage over a time window (minimum 5 runs)
- Latency Threshold: a run took longer than a fixed duration
- Latency Spike: a run was a configurable percentage slower than the recent average (minimum 5 runs)
- Cost Threshold: a run cost more than a credit threshold
- Error Count: N or more errors occurred within a time window
- No Activity: a watched workflow had no runs for a configurable number of hours
Workflow Scope
By default the trigger watches every workflow in the workspace. Select specific workflows to narrow it. The workflow containing the trigger is always excluded — it never receives events about itself.
Outputs
All events include event, timestamp, workflowId, and workflowName (the source workflow). Additional fields depend on the event type:
- runId: the run that completed
- durationMs: run duration in milliseconds
- cost: run cost in credits
- finalOutput: the run's final output (truncated when large)
Run-backed conditions nest the run that tripped them under triggeringRun:
- triggeringRun.runId, triggeringRun.durationMs, triggeringRun.cost, triggeringRun.finalOutput
No Activity has no triggering run, so it carries only the base fields.
- version: the deployment version number that was activated
Behavior
- The workflow containing the Sim trigger must be deployed for events to fire.
- Runs started by a Sim trigger never emit workspace events, so side-effect workflows cannot chain or loop.
- Alert conditions fire at most once per cooldown window (one hour, or the inactivity window for No Activity).
- Event delivery is fire-and-forget: side-effect runs are billed like any other run and are subject to workspace rate limits.
Trigger configuration is snapshotted at deploy time. After changing the event type, workflow scope, or thresholds, redeploy the workflow for the changes to take effect.