---
title: Sim Workspace Events
---

import { Callout } from 'fumadocs-ui/components/callout'
import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
import { FAQ } from '@/components/ui/faq'

The Sim Workspace Events 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 Workspace Events trigger block:

**Plain events** — fire on every occurrence:

<ul className="list-disc space-y-1 pl-6">
  <li><strong>Run Error</strong>: a watched workflow's run failed</li>
  <li><strong>Run Success</strong>: a watched workflow's run completed successfully</li>
  <li><strong>Workflow Deployed</strong>: a watched workflow was deployed (including redeploys and version rollbacks)</li>
  <li><strong>Workflow Undeployed</strong>: a watched workflow was taken offline</li>
</ul>

**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:

<ul className="list-disc space-y-1 pl-6">
  <li><strong>Consecutive Failures</strong>: the last N runs all failed</li>
  <li><strong>Failure Rate</strong>: failure rate meets or exceeds a percentage over a time window (minimum 5 runs)</li>
  <li><strong>Latency Threshold</strong>: a run took longer than a fixed duration</li>
  <li><strong>Latency Spike</strong>: a run was a configurable percentage slower than the recent average (minimum 5 runs)</li>
  <li><strong>Cost Threshold</strong>: a run cost more than a credit threshold</li>
  <li><strong>Error Count</strong>: N or more errors occurred within a time window</li>
  <li><strong>No Activity</strong>: a watched workflow had no runs for a configurable number of hours</li>
</ul>

## 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:

<Tabs items={['Run Events', 'Alert Conditions', 'Workflow Deployed']}>
  <Tab>
    <ul className="list-disc space-y-1 pl-6">
      <li><strong>runId</strong>: the run that completed</li>
      <li><strong>durationMs</strong>: run duration in milliseconds</li>
      <li><strong>cost</strong>: run cost in credits</li>
      <li><strong>finalOutput</strong>: the run's final output (truncated when large)</li>
    </ul>
  </Tab>
  <Tab>
    <p>Run-backed conditions nest the run that tripped them under <code>triggeringRun</code>:</p>
    <ul className="list-disc space-y-1 pl-6">
      <li><strong>triggeringRun.runId</strong>, <strong>triggeringRun.durationMs</strong>, <strong>triggeringRun.cost</strong>, <strong>triggeringRun.finalOutput</strong></li>
    </ul>
    <p>No Activity has no triggering run, so it carries only the base fields.</p>
  </Tab>
  <Tab>
    <ul className="list-disc space-y-1 pl-6">
      <li><strong>version</strong>: the deployment version number that was activated</li>
    </ul>
    <p>Workflow Undeployed carries only the base fields.</p>
  </Tab>
</Tabs>

## Behavior

<ul className="list-disc space-y-1 pl-6">
  <li>The workflow containing the Sim Workspace Events trigger must be <strong>deployed</strong> for events to fire.</li>
  <li>Runs started by a Sim Workspace Events trigger never emit workspace events, so side-effect workflows cannot chain or loop.</li>
  <li>Alert conditions fire at most once per cooldown window (one hour, or the inactivity window for No Activity).</li>
  <li>Event delivery is fire-and-forget: side-effect runs are billed like any other run and are subject to workspace rate limits.</li>
</ul>

<Callout type="info">
  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.
</Callout>

<FAQ items={[
  { question: "Why isn't my Sim Workspace Events trigger firing?", answer: "The workflow containing the trigger must be deployed — events only fire for deployed workflows. Also note the trigger never fires for the workflow it lives in, and runs started by another Sim Workspace Events trigger don't emit events." },
  { question: "Can a workflow started by a Sim Workspace Events trigger fire other Sim Workspace Events triggers?", answer: "No. Runs started by a Sim Workspace Events trigger never emit workspace events. This prevents chains and infinite loops — an alert workflow that fails can't re-trigger itself." },
  { question: "How often do alert conditions fire?", answer: "At most once per cooldown window per trigger block. Most conditions use a one-hour cooldown; No Activity uses the configured inactivity window, evaluated per watched workflow." },
  { question: "What unit is cost in?", answer: "Credits, both for the Cost Threshold configuration and the cost field in event payloads." },
]} />
