# Alerts (/logs-debugging/alerts)



Use a [Sim Workspace Events trigger](/workflows/triggers/sim) to run an alert workflow when another workflow fails, slows down, exceeds a cost threshold, or goes quiet. Add delivery blocks for the channel you use, such as Slack, email, or an incident API.

## Before you start [#before-you-start]

You need permission to create and deploy the alert workflow, a credential for its delivery service, and a watched test workflow where you can reproduce the condition.

## Example: notify Slack after repeated failures [#example-notify-slack-after-repeated-failures]

1. Create a workflow with **Sim Workspace Events** as its trigger.
2. Set **Event** to **Consecutive Failures** and **Consecutive Failures** to `3`.
3. Select the source **Workflows**. Leave the field empty to watch the workspace.
4. Add a Slack block that sends a message to your incident channel. Choose the intended Slack account and channel.
5. Include the trigger's `workflowName` and `triggeringRun.runId` in the message using the reference picker. For a trigger named `workspaceevent`, the message can be:

```text
Workflow <workspaceevent.workflowName> has failed repeatedly.
Latest run: <workspaceevent.triggeringRun.runId>
```

6. Deploy the alert workflow to activate it.

## Verify the alert [#verify-the-alert]

Trigger three consecutive failures in a watched test workflow. Inspect the alert workflow's [run log](/logs-debugging), confirm its delivery block completed, and check the Slack message for the source workflow and run ID.

## Choose another condition [#choose-another-condition]

Choose **Run Error** to respond to each failed run. Other conditions include failure rate, error count, latency, cost, and inactivity. Cost thresholds use credits. See the [event and rule reference](/workflows/triggers/sim) for settings, defaults, and event-specific outputs.

Run-backed alert rules have a one-hour cooldown after firing. **No Activity** has a per-watched-workflow cooldown of at least one hour or the inactivity window, whichever is longer. Plain events such as Run Error have no rule cooldown. Rate-based rules need at least five runs in their window. A subscription does not receive events about its own workflow, and runs started by this trigger do not emit new workspace events.

## If an alert is missing [#if-an-alert-is-missing]

Delivery behavior comes from the action blocks you configure. Check that the alert workflow is deployed, the source workflow matches its filter, the condition and cooldown allow it to fire, and the delivery block completed successfully.

## Related docs [#related-docs]

* [Sim Workspace Events](/workflows/triggers/sim) for event settings and outputs
* [Logs](/logs-debugging) for tracing a failed alert run