Workflows

Workflows automate actions when telemetry or incident state changes in Moneat. Each workflow follows the same pattern:

When an event occurs, if its conditions match, run these steps.

Use workflows to notify responders, coordinate incident response, enrich alerts with telemetry, and keep external systems up to date without repeating the same process manually.

Every organization starts with two enabled notification workflows:

Edit or disable these workflows to change who is notified and where messages are sent.

How a workflow fits together

A workflow combines triggers, optional conditions, and one or more steps.

Triggers

A trigger starts the workflow. Common choices include an alert firing or resolving, an incident changing, a schedule reaching its next occurrence, or an authenticated manual or API request.

The selected trigger also determines which information is available to conditions and steps. For example, an alert trigger exposes the alert title, priority, status, source, and URL.

See Workflows Reference for every trigger identifier and its context fields.

Conditions

Conditions limit which matching events create a run. For example, a notification workflow might run only for P0 and P1 alerts in production, or only when the affected service is checkout.

Conditions can combine rules with and, or, and not groups. The editor shows the fields and operators supported by the selected trigger and prevents incompatible comparisons before publication.

Steps

Steps describe what happens after the trigger and conditions match. A simple workflow might send an email or post to Slack. More advanced workflows can search telemetry, page on-call responders, create or update incidents, call approved connectors, wait for a signal, or run branches in parallel.

The available steps depend on the installed edition, enabled capabilities, permissions, and configured connections. See Workflows Reference for action identifiers, outputs, control nodes, and availability rules.

Create a workflow

Open Workflows in the sidebar, then select New Workflow.

1. 1
   Choose a trigger

   Select the event, request, webhook, or schedule that should start the workflow.
2. 2
   Name the workflow

   Use a name that describes the result, such as "Notify Slack for critical host alerts".
3. 3
   Add conditions

   Limit the workflow to the services, priorities, environments, or other values that matter.
4. 4
   Configure steps

   Add the notifications, incident actions, telemetry queries, or control flow the response needs.
5. 5
   Test and publish

   Test the draft with sample data, resolve validation errors, then publish an immutable version.

Example: notify Slack for critical alerts

Create a workflow with When an alert triggers, add a condition for priorities P0 and P1, then add Post to Slack. Use message variables to include useful alert context:

{{alert.title}}
Priority: {{alert.priority}}
Source: {{alert.source}}
View: {{alert.url}}

Use Preview to render representative Slack, Discord, and email messages without sending them. You can also test an individual notification step against its configured destination without creating a workflow run.

For API request bodies, signed-webhook examples, schedules, connectors, and typed graph definitions, see Workflows Reference.

Control how often a workflow runs

The Run once per setting controls idempotency: it determines which matching events belong to the same logical run.

Firing alert workflows default to the alert episode and notification sequence. Resolved-alert workflows also include the alert status, so firing and recovery notifications do not collapse into the same run.

Test before publishing

Editing a published workflow creates a draft. Draft tests use representative or previously observed trigger data and do not run external actions. Publishing promotes the validated draft to an immutable version; runs already in progress continue on the version that admitted them.

Use a preview when you only need to check rendered notification content. Use a draft test when you need to inspect conditions, branches, inputs, and outputs together.

View and recover runs

Open a workflow to view its recent runs. Each run shows the workflow version, trigger, run identity, step progress, attempts, waits, redacted inputs and outputs, and any failure details.

Use run history to confirm that the expected events matched and to diagnose failed steps. Depending on the run state and your access, you can retry a failed node, resume a safe wait, replay the original version, cancel an active run, or move an irrecoverable run to dead letter.

See Workflows Reference for execution states and recovery API operations.

Advanced workflows

Workflows also support schedules, signed webhooks, typed inputs and outputs, approvals, reusable subflows, bounded loops, and parallel branches. These features are useful when a response must wait for a person or event, coordinate several systems, or expose a stable automation contract.

Use the Workflows Reference when building against the API, Terraform, or an AI agent, or whenever you need the exact supported identifiers, schemas, policies, and limits.