Documentationbreadcrumb arrow Grafana Cloudbreadcrumb arrow Platformbreadcrumb arrow Workflowsbreadcrumb arrow Referencebreadcrumb arrow Blueprintsbreadcrumb arrow Create Jira issue for incident follow-ups
Public preview Grafana Cloud
Last reviewed: November 9, 2026

Create Jira issue for incident follow-ups

Note

Grafana Workflows is currently in public preview. Grafana Labs offers limited support, and breaking changes might occur prior to the feature being made generally available.

When a critical or major incident is resolved, open a Jira issue to track follow-up work and link it on the incident timeline.

This Grafana Workflows blueprint is in the Integrations category of the Blueprints library.

Before you begin

To use this blueprint, you need:

  • Grafana IRM set up on your stack.
  • A workflow secret named jira-api-token.

To create a secret, refer to Manage secrets.

Steps

Steps run in order from first to last. A step inside a switch branch runs only when Workflows chooses that branch.

StepIDTypeDescription
Create the Jira issuecreate-issuehttp.callCreates a follow-up issue. Replace your-company.atlassian.net with your Jira site, set authUsername to the Jira account email that owns the API token, and set the project key in the body. Also create a workflow secret named jira-api-token that holds a Jira API token. Change the issue type or labels if needed.
Fail if the issue was not createdcheck-createdfilterFails the run with an error when Jira does not create the issue. No changes needed.
Link the issue on the incidentlink-issueincident.add-noteAdds a link to the new Jira issue on the incident timeline. No changes needed.

For the inputs and outputs of each step type, refer to Step and trigger types reference.

Before you turn on the workflow, customize any steps that need input from you, such as a channel ID or a schedule name. Each step’s description says what to set.

Workflow definition

Save this definition as a YAML file to create the workflow with gcx, the Workflows API, or Terraform, or give it to a coding agent as an example. Replace FOLDER_UID with the UID of the folder for the workflow. Blueprints start disabled, so finish customizing the steps before you set enabled to true. For details, refer to Manage workflows as code.

YAML 
apiVersion: workflows.ext.grafana.app/v1alpha1
kind: Definition
metadata:
  name: create-jira-issue-for-incident
  annotations:
    grafana.app/folder: <FOLDER_UID>
spec:
  name: Create Jira issue for incident follow-ups
  enabled: false
  runOnceFor: 'jira:${inputs.data.incidentID}'
  startWhen:
    matchingRules:
      - eventNameRegex: 'grafana_irm_app\.incident\.updated'
        filter: "inputs.data.eventKind == 'incident_updated_status' && inputs.data.newStatus == 'resolved' && resources.incident.event.severity.matches('(?i)^(critical|major)$') && !resources.incident.event.isDrill"
    schedules: []
  resources:
    secrets:
      jiraApiToken: 'secret://jira-api-token'
  steps:
    - id: create-issue
      type: http.call
      name: Create the Jira issue
      description: >-
        Creates a follow-up issue. Replace your-company.atlassian.net with your Jira site, set
        authUsername to the Jira account email that owns the API token, and set the project key in
        the body. Also create a workflow secret named jira-api-token that holds a Jira API token.
        Change the issue type or labels if needed.
      inputs:
        method: 'POST'
        url: 'https://your-company.atlassian.net/rest/api/2/issue'
        headers: '["Accept: application/json"]'
        body: |
          {
            "fields": {
              "project": {
                "key": ""
              },
              "issuetype": {
                "name": "Task"
              },
              "summary": ${json_stringify('Follow-ups for incident ' + inputs.data.incidentID + ': ' + resources.incident.event.title)},
              "description": ${json_stringify('Incident: ' + resources.incident.event.overviewURL + '\nSeverity: ' + resources.incident.event.severity + '\n\n' + resources.incident.event.summary)},
              "labels": [
                "incident-follow-up"
              ]
            }
          }
        authMethod: 'basic'
        authUsername: ''
        authPassword: '${resources.secret.jiraApiToken}'
    - id: check-created
      type: filter
      name: Fail if the issue was not created
      description: Fails the run with an error when Jira does not create the issue. No changes needed.
      inputs:
        condition: "steps['create-issue'].outputs.responseCode == 201"
        failOnExit: 'true'
    - id: link-issue
      type: incident.add-note
      name: Link the issue on the incident
      description: Adds a link to the new Jira issue on the incident timeline. No changes needed.
      inputs:
        incidentID: '${inputs.data.incidentID}'
        message: "Follow-up work is tracked in Jira issue ${json_parse(steps['create-issue'].outputs.responseBody).key}."

How it works

This section explains when the workflow runs and how its steps work together.

When it runs

This blueprint starts on the grafana_irm_app.incident.updated event.

Its trigger filter starts a run only when this CEL expression is true:

text 
inputs.data.eventKind == 'incident_updated_status' && inputs.data.newStatus == 'resolved' && resources.incident.event.severity.matches('(?i)^(critical|major)$') && !resources.incident.event.isDrill

It runs at most once for each run-once key. This blueprint’s key is jira:${inputs.data.incidentID}, so a later event with the same key doesn’t start another run. For details, refer to Deduplicate workflow runs.

How the steps fit together

These notes cover how the steps connect and which Workflows behaviors the blueprint relies on.

  • Triggers on eventKind incident_updated_status when newStatus is resolved, filtered in the trigger to Critical and Major incidents that are not drills.
  • runOnceFor keys on the incident ID, so you get one issue per incident.
  • http.call uses basic auth.
  • authUsername is the Jira account email and authPassword references a Jira API token stored as a workflow secret.
  • Both are secretString parameters, so their values are redacted from run history.
  • The body uses the Jira REST API v2 issue format, because v2 accepts a plain-text description.
  • Every dynamic value goes through json_stringify() to stay valid JSON.
  • A filter with failOnExit fails the run unless Jira returns 201.
  • The last step reads the new issue key with json_parse(steps[‘create-issue’].outputs.responseBody).key.
  • Customize the Jira site in the URL, the account email, the project key, the issue type, and the labels.

Next steps