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.

Response rules are workflows too, including the default incident response every organization starts with. They are listed on the Workflows page and open on the same canvas, but they are created, ordered, and turned on or off under Response rules.

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 on the Alert triggered trigger, 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. Publishing promotes the validated draft to an immutable version; runs already in progress continue on the version that admitted them.

A test run plans the workflow against trigger data without running any step. In the editor it tests your edits, or the published version once there is one; on the workflow's page it tests the published version or the saved draft. Start from example data, a saved test case, or data the trigger has sent before. Example data names one of your teams, preferring one whose escalation policy is published, and the values the trigger's conditions ask for, so the test reaches the workflow's steps. The fields the workflow uses come first; a test with a field left empty shows what the workflow does without it. Choose when the run starts, the time zone its times read in, and when pages are acknowledged. The result shows when each step would run, who each page reaches, when the page can go out and when acknowledgement is due, and how the run changes if pages are acknowledged sooner, later, or not at all. When the workflow decides on the incident's priority or on working hours, the result also compares a high and a routine priority, no priority, and starts inside and outside the calendar's hours.

A test run can't know what another system returns or what a person decides, so it marks an HTTP request, a connector, an investigation, an approval, and a Slack, email, or Discord message Unknown, and every step after it Conditional. A step that runs after a wait for an approval or another event shows the window it falls in. Steps that follow from the acknowledgement you chose are marked Assumed. The result is Out of date once you change an input, or when something it read changes, such as who is on call or a calendar's hours.

Use a preview when you only need to check rendered notification content. See Test runs for what a test run reads and returns.

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.