Documentation Grafana Cloud Alerts and IRM Workflows Load incident data

Load incident data

Incident resources let workflows load full Grafana Incident data and reference individual fields in step inputs. The engine fetches incidents at the start of workflow execution, before any steps run.

There are two ways incidents are loaded:

• Automatically for workflows triggered by incident events
• Explicitly through the resources.incidents section of the workflow definition

Automatic loading for incident events

When a workflow triggers on an incident event (any event matching grafana_irm_app.incident.*), the engine automatically fetches the full incident and makes it available under the key event:

YAML Copy

spec:
  name: Respond to incident
  startWhen:
    matchingRules:
      - eventNameRegex: "grafana_irm_app\\.incident\\..*"
  steps:
    - id: notify
      type: slack.message.post
      inputs:
        channelID: "C0123456789"
        messageText: "Incident ${resources.incident.event.title} is ${resources.incident.event.status} (${resources.incident.event.severity})"

No configuration is required. The engine detects the incident event, extracts the incident ID from the event payload, and fetches the current incident data from the Grafana Incident API.

Declare incident resources explicitly

To load incidents that are not part of the triggering event, declare them in the resources.incidents section. Each entry maps a reference name to an incident URI using the incident://id/ scheme:

YAML Copy

spec:
  resources:
    incidents:
      related: "incident://id/456"
      current: "incident://id/${inputs.incident.incidentID}"

Values must use the incident://id/ URI prefix followed by the numeric incident ID. The id/ path segment distinguishes ID lookups from future URI types. CEL expressions are supported in the path and are evaluated before the URI is parsed:

• Literal URIs: A constant incident URI such as "incident://id/456".
• CEL expressions in the URI: Use ${expression} in the path, for example "incident://id/${inputs.incident.incidentID}" to pull the ID from the triggering event data.

Reference incident fields in step inputs

Access incident fields using ${resources.incident.<key>.<field>} syntax in step inputs:

YAML Copy

steps:
  - id: post-summary
    type: slack.message.post
    inputs:
      channelID: "C0123456789"
      messageText: |
        Incident: ${resources.incident.event.title}
        Status: ${resources.incident.event.status}
        Severity: ${resources.incident.event.severity}
        Created: ${resources.incident.event.createdTime}

Available fields

The incident object contains these fields, using camelCase names that match the Grafana Incident API:

Combine automatic and explicit resources

A workflow can use both automatic and explicit incident resources. When a workflow triggers on an incident event and also declares explicit resources, both are available. If an explicit entry uses the key event, it overrides the auto-loaded incident:

YAML Copy

spec:
  startWhen:
    matchingRules:
      - eventNameRegex: "grafana_irm_app\\.incident\\.updated"
  resources:
    incidents:
      related: "incident://id/456"
  steps:
    - id: compare
      type: transform
      inputs:
        template: "Event incident: ${resources.incident.event.title}, Related: ${resources.incident.related.title}"

In this example, resources.incident.event is auto-loaded from the triggering incident event, and resources.incident.related is loaded from the explicitly declared ID.

Error handling

If any incident fails to load (invalid ID, API unreachable, or authentication failure), the workflow fails immediately before any steps execute. This applies to both auto-loaded and explicitly declared incidents.

Next steps

• Create workflows
• Load alert group data
• Use CEL expressions
• Manage secrets
• Step types reference