Send Incident Data to LinearB Using Jira Automation

Send your Jira incident lifecycle directly to LinearB's Incident API using Jira Cloud automation. This keeps Change Failure Rate (CFR) and Mean Time to Recovery (MTTR) accurate without requiring custom code or additional servers.

Each time an incident is created or changes status in Jira, an automation rule sends the corresponding incident data and timestamp to LinearB.

---

Overview

This configuration uses three Jira automation rules. Each rule represents a stage in the incident lifecycle and sends the corresponding request to LinearB.

Event	Jira action	LinearB action
Incident created	Issue is created	Creates the incident and sets issued_at
Work in progress	Issue transitions to the work-started status	Updates the incident and sets started_at
Work completed	Issue transitions to a resolved status	Updates the incident and sets ended_at

---

Prerequisites

In LinearB

1. Generate a LinearB API token from Company Settings → API Tokens.
2. Copy the token. You will use it when configuring the Jira automation rules.
3. Go to Company Settings → Project Management → Incidents.
4. Set Incidents Detection to API Integration.
5. Click Save.

In Jira

Before creating the automation rules, make sure you have:

• Permission to create project or global Jira automation rules.
• A consistent way to identify incident issues. For example, use a dedicated Incident issue type, project, or label.
• Identified the Jira workflow status that represents work starting, such as In Progress.
• Identified the workflow statuses that represent resolution, such as Done, Resolved, or Closed.

The examples below assume an issue type named Incident. Adjust the conditions if your Jira configuration identifies incidents differently.

---

Map Jira Values to the Incident API

Every request contains your LinearB API token and identifies the incident using its Jira issue key.

LinearB field	Jira smart value	Description
provider_id	{{issue.key}}	Unique identifier for the incident. The same value is used as the path parameter when updating the incident.
http_url	{{baseUrl}}/browse/{{issue.key}}	Link to the Jira issue.
title	{{issue.summary}}	Jira issue summary.
issued_at	{{issue.created...}}	Issue creation time in ISO 8601 UTC format.
started_at	{{now...}}	Time the incident transitions to the work-started status.
ended_at	{{now...}}	Time the incident transitions to a resolved status.

---

Configure Common Rule Settings

Each Jira automation rule ends with a Send web request action. Configure the following settings for every rule:

• HTTP headers: x-api-key = your LinearB API token
• Content-Type: application/json
• Web request body: Select Custom data and use the JSON body provided for the corresponding rule.
• Leave Delay execution until we've received a response unchecked unless another automation action depends on the response.

---

Create Rule 1: Incident Created

This rule creates the incident in LinearB and records issued_at.

Trigger: Issue created

Condition: Issue fields condition → Issue Type equals Incident or the equivalent condition used by your Jira configuration.

Action: Send web request

Method: POST

Web request URL:

https://public-api.linearb.io/api/v1/incidents

Custom data:

{
            "provider_id": "{{issue.key}}",
            "http_url": "{{baseUrl}}/browse/{{issue.key}}",
            "title": "{{issue.summary}}",
            "issued_at": "{{issue.created.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}"
          }

---

Create Rule 2: Work in Progress

This rule runs when the incident transitions to the status that represents work starting and records started_at.

Trigger: Issue transitioned

Condition: Status condition → Destination status equals In Progress, and Issue Type equals Incident.

Action: Send web request

Method: PATCH

Web request URL:

https://public-api.linearb.io/api/v1/incidents/{{issue.key}}

Custom data:

{
            "started_at": "{{now.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}"
          }

---

Create Rule 3: Work Completed

This rule runs when the incident transitions to a resolved status and records ended_at.

Trigger: Issue transitioned

Condition: Status condition → Destination status equals Done, Resolved, or Closed , and Issue Type equals Incident.

Action: Send web request

Method: PATCH

Web request URL:

https://public-api.linearb.io/api/v1/incidents/{{issue.key}}

Custom data:

{
            "ended_at": "{{now.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}"
          }

---

Link Incidents to Teams and Repositories

Incident API requests can include optional team and repository information. Adding this information allows LinearB to associate incidents more accurately with the teams and code affected by the incident.

Add a Team to the Request

Add a teams array containing LinearB team names. Team names must be lowercase and must match the corresponding team names in LinearB.

For example:

{
            "provider_id": "{{issue.key}}",
            "http_url": "{{baseUrl}}/browse/{{issue.key}}",
            "title": "{{issue.summary}}",
            "issued_at": "{{issue.created.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}",
            "teams": ["team a"]
          }

You can also add the team later using a PATCH request because the teams array is supported when updating an incident.

Why Link a Team to an Incident?

LinearB calculates Change Failure Rate and Mean Time to Recovery by team. Associating the incident with its owning team allows the incident to contribute to that team's reliability metrics.

• The incident appears in the appropriate team's CFR and MTTR widgets and in the Incidents view when filtered by team.
• Incidents associated with sub-teams roll up to parent groups that aggregate those teams.
• Team association helps ensure company-wide metrics correctly attribute an incident to the team responsible for the affected work.

Infer the Team from a Jira Project

Jira boards are typically based on projects or filters. Jira automation can therefore use the project, such as {{issue.project.key}} or {{issue.project.name}}, as the basis for mapping the issue to a LinearB team.

Jira does not automatically know your LinearB team names, so configure the mapping in Jira.

Option A: Create a Lookup Table

Jira Cloud automation supports key/value lookup tables. Add a Create lookup table action before the web request and create a project-to-team mapping.

For example:

• MOB → mobile
• WEB → web platform
• PAY → payments

Then reference the table in the request:

"teams": ["{{teamMap.get(issue.project.key).toLowerCase()}}"]

The toLowerCase() function ensures that the value sent to LinearB satisfies the lowercase requirement.

This approach keeps the project-to-team mapping in one editable location. To support another project, add another entry to the lookup table.

Option B: Use a Jira Custom Field

Create a Jira custom field such as LinearB Team and assign the appropriate value for each project or board.

Reference the field directly:

"teams": ["{{issue.LinearB Team}}"]

You can also reference the Jira field ID:

"teams": ["{{issue.customfield_10050}}"]

Choose the approach that best matches how your Jira projects and teams are managed.

Include Repository URLs

If the affected repository is stored on the Jira issue, for example in a custom field or fixVersion, include it in the repository_urls array.

Provide the full repository URL exactly as it appears in LinearB, typically the clone URL.

For a custom field named Repository URL:

"repository_urls": ["{{issue.Repository URL}}"]

Team and repository information can be included in the same request:

{
            "provider_id": "{{issue.key}}",
            "http_url": "{{baseUrl}}/browse/{{issue.key}}",
            "title": "{{issue.summary}}",
            "issued_at": "{{issue.created.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}",
            "teams": ["{{teamMap.get(issue.project.key).toLowerCase()}}"],
            "repository_urls": ["{{issue.Repository URL}}"]
          }

---

Troubleshoot the Integration

• Use ISO 8601 timestamps. convertToTimeZone("UTC") produces UTC timestamps ending in Z, for example 2026-07-23T14:05:00Z. Incorrect date formats are a common cause of 422 responses.
• Keep provider_id unchanged. Rules 2 and 3 locate the incident using the same {{issue.key}} value used when the incident was created.
• PATCH request returns 422. Some API versions may require title and issued_at to also be included in the update request.

For example:

{
            "title": "{{issue.summary}}",
            "issued_at": "{{issue.created.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}",
            "started_at": "{{now.convertToTimeZone("UTC").format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}"
          }

• 401 Unauthorized: Check the x-api-key value and confirm that the API token belongs to the correct LinearB organization.
• Optional enrichment: You can add teams, services, or repository_urls arrays to requests to improve incident attribution.
• Use fewer Jira rules: Rules 2 and 3 can be combined into a single Issue transitioned rule with Jira If/Else conditions based on the destination status.

---

Verify the Integration

1. Create a test incident in Jira.
2. Move the issue to In Progress.
3. Move the issue to Done or your resolved status.
4. In LinearB, go to Metrics → Git Activity → Incidents.
5. Confirm that the incident appears and that issued_at, started_at, and ended_at are populated.
6. Confirm that the incident contributes to the CFR and MTTR widgets on the Metrics dashboard.

---

References

• LinearB Incident API reference
• Incident API – Configure Incident Detection for DORA Metrics
• API – Incidents
• Generate LinearB API Tokens
• Jira Automation Actions
• Jira Smart Values – Date and Time