Documentation Grafana Cloud Alerts and IRM Workflows Step and trigger types reference

Step and trigger types reference

Step types

Steps are the individual actions in a workflow. They execute in order from first to last. Each step has a type, an ID, and a set of inputs. Every step produces outputs that later steps can reference through the workflow context using CEL expressions, for example, ${steps.my-step.outputs.responseBody}.

For details on connecting steps with the workflow context, refer to Use CEL expressions.

General

HTTP call (http.call)

Make an HTTP request to any URL with any method and body. Supports bearer token and basic authentication using secrets.

Inputs:

Outputs:

Execute code (code.execute)

Run sandboxed code inside a workflow. The full workflow context is available as a built-in variable, and additional named arguments can be passed as a JSON object. Code runs in an isolated sandbox with no network access and a temporary filesystem.

Currently supported languages: Python.

Inputs:

Outputs:

Injected variables:

Two variables are automatically available inside the sandbox:

The context variable has the following structure:

JSON Copy

{
  "inputs": { },
  "steps": {
    "step-id": {
      "outputs": { }
    }
  },
  "resources": {
    "incident": { },
    "alertgroup": { }
  }
}

• context["inputs"] contains the trigger event data or manual test input.
• context["steps"] contains outputs from all previously executed steps, keyed by step ID.
• context["resources"] contains resolved resource data (incidents, alert groups). The secret namespace is always stripped before code execution.

Example: process data from a previous step

This example shows a workflow where a code step reads the response from an earlier HTTP call, processes it, and outputs structured JSON for a downstream filter step:

YAML Copy

steps:
  - id: fetch-status
    type: http.call
    name: "Get service status"
    inputs:
      method: "GET"
      url: "https://api.example.com/status"

  - id: analyze
    type: code.execute
    name: "Analyze status response"
    inputs:
      language: python
      code: |
        import json

        response = context["steps"]["fetch-status"]["outputs"]["responseBody"]
        data = json.loads(response)

        unhealthy = [s for s in data.get("services", []) if s["status"] != "healthy"]
        threshold = args.get("threshold", 1)

        print(json.dumps({
            "unhealthy_count": len(unhealthy),
            "unhealthy_services": [s["name"] for s in unhealthy],
            "should_alert": len(unhealthy) >= threshold,
        }))
      args:
        threshold: "${inputs.alertThreshold}"

  - id: check-alert
    type: filter
    name: "Alert if threshold exceeded"
    inputs:
      condition: "steps['analyze'].outputs.success == true"
      failOnExit: "true"

Example: simple scheduled check

YAML Copy

steps:
  - id: run-check
    type: code.execute
    inputs:
      language: python
      code: |
        has_inputs = len(context.get("inputs", {})) > 0
        print(f"Scheduled run, has trigger inputs: {has_inputs}")

Downstream steps reference code output using CEL expressions, for example, ${steps['analyze'].outputs.stdout}.

No operation (noop)

Perform no action. Use this step as a placeholder during development or as a default branch target in switch steps.

This step has no inputs and produces no outputs.

Flow control

Transform (transform)

Evaluate a template string with embedded CEL expressions to generate dynamic content. Use ${expression} syntax to embed expressions that reference workflow inputs and previous step outputs.

Inputs:

Outputs:

Filter (filter)

Gate workflow execution on a CEL condition. If the condition evaluates to false, the workflow stops and no further steps execute.

Inputs:

Outputs:

Switch (switch)

Conditionally execute different sets of steps based on CEL expressions. Each branch has a condition and its own list of steps. The first branch whose condition evaluates to true runs. Include a default branch with no condition as a fallback.

For details on how to define branches, refer to Create workflows.

Outputs:

Wait (wait)

Pause workflow execution for a specified number of seconds.

Inputs:

Outputs:

Incident

Incident steps operate on Grafana Incidents. You can pass incident IDs directly or reference them from incident resources loaded into the workflow context. For details on loading incident data, refer to Load incident data.

Add participant to incident (incident.add-participant)

Add a user to a Grafana Incident with a specific role.

Inputs:

Outputs:

Set incident field (incident.set-field)

Update a field on a Grafana Incident, including title, status, severity, or role assignments.

Inputs:

Outputs:

Slack

Create Slack channel (slack.channel.create)

Create a new public or private Slack channel.

Inputs:

Outputs:

Post message to Slack channel (slack.message.post)

Post a message to a Slack channel. Supports plain text, Block Kit blocks for rich formatting, attachments, and threaded replies.

Inputs:

Outputs:

Archive Slack channel (slack.channel.archive)

Archive a Slack channel.

Inputs:

Outputs:

Add bookmark to Slack channel (slack.channel.add-bookmark)

Add a bookmark link to a Slack channel.

Inputs:

Outputs:

Add users to Slack channel (slack.channel.add-users)

Invite users to a Slack channel by their Slack user IDs.

Inputs:

Outputs:

IRM

Page user via IRM (irm.page-user)

Create an IRM/OnCall escalation to page a user. Optionally associates the escalation with an incident and includes urgency and message context.

Inputs:

Outputs:

Trigger types

Triggers define when a workflow starts. You configure triggers in the startWhen section of a workflow definition. For details on configuring triggers, refer to Configure triggers.

Event trigger

An event trigger starts a workflow when an incoming event matches a regular expression pattern. Events arrive on NATS subjects following the format {app}.{instance-id}.{resource-type}.{event-type}.

You define event triggers using matching rules. Each rule contains a regex pattern that the engine tests against incoming event subjects. If any rule matches, the workflow starts.

Configuration:

Example:

YAML Copy

startWhen:
  matchingRules:
    - eventNameRegex: "grafana_irm_app\\.incident\\.created"
    - eventNameRegex: "grafana_irm_app\\.alert_groups\\.fired"

A workflow can have multiple matching rules. The workflow triggers if any rule matches.

Available event sources

The following table lists the event sources that can trigger workflows:

Event names follow the pattern {app}.{resource-type}.{event-type}.

Schedule trigger

A schedule trigger starts a workflow at recurring times using a cron expression. Schedules use the standard five-field Unix cron format and run in UTC.

Configuration:

Example:

YAML Copy

startWhen:
  schedules:
    - "0 9 * * 1-5"
    - "0 0 1 * *"

A workflow can have multiple schedules. Each schedule triggers the workflow independently.

Cron field reference:

Manual trigger

A manual trigger starts a workflow only through the UI or API. Any workflow can be triggered manually regardless of whether it has event or schedule triggers configured.

To trigger a workflow manually in the editor, click Test and provide sample input data as a JSON object.

Manual-only workflows have an empty startWhen section:

YAML Copy

startWhen:
  matchingRules: []
  schedules: []

Combine triggers

A workflow can have both event and schedule triggers. The workflow starts when any matching rule matches an incoming event or when any schedule fires.

YAML Copy

startWhen:
  matchingRules:
    - eventNameRegex: "grafana_irm_app\\.incident\\.created"
  schedules:
    - "0 9 * * 1-5"