Take action now with LaunchDarkly built-in Jira ticket support

This post walks through how LaunchDarkly Observability turns alerts, error groups, and sessions into real Jira tickets through the Atlassian Forge app, and how Vega can draft those tickets from an investigation so production signal becomes tracked work.

The problem

An error group is climbing. You screenshot the stack trace along with other relevant information, paste it into Jira, and lose half the context on the way. Three Slack threads later, the ticket still isn’t filed. Three pieces close that gap:

Atlassian Forge: The LaunchDarkly for Jira app, with webtriggers that list Jira projects and create issues.
LaunchDarkly observability: Error groups and sessions, each with a Create Jira issue action, and alerts, which take Jira as a notification destination.
Vega: The LaunchDarkly observability agent, which drafts a ticket with an in-depth description after an investigation and files it after you confirm.

Why it matters

When you switch back and forth between platforms like LaunchDarkly and Jira, context can get lost. For example, a ticket titled “fix errors” with no link back to the error group fails to point others in the correct direction. With Jira support in LaunchDarkly, every ticket carries its source, a link, and a description written with actionable evidence and next steps. Instead of half-baked tickets with vague descriptions, you get a clean summary of the ticket context and follow-up steps, with help from Vega.

Requirements

To use this flow, you need:

A LaunchDarkly account with observability enabled
The LaunchDarkly for Jira marketplace app configured with a LaunchDarkly API access token
(Optional) Generative AI (GenAI) enabled on the account, if you want to Create with Vega

To configure the API access token, create a custom role, click Inline policy, then click View JSON in the “Edit policy” box. Paste these permissions:

[
  {
    "resources": ["proj/*:env/*:flag/*"],
    "actions": ["createFlagLink", "updateFlagLink", "deleteFlagLink"],
    "effect": "allow"
  },
  {
    "resources": ["proj/*"],
    "actions": ["viewProject"],
    "effect": "allow"
  },
  {
    "resources": ["integration/*"],
    "actions": ["createIntegration", "deleteIntegration"],
    "effect": "allow"
  }
]

The Create access token dialog in LaunchDarkly, with the name set to "jira integration", the Role menu set to "Inline policy", and an Edit policy box with a View JSON button. — The Create access token dialog with an inline policy, where you paste the Jira permissions.

For more details, read Jira Cloud.

How it fits together

The Forge app exposes two webtriggers for this flow:

ld-jira-meta-trigger returns Jira projects and their issue types. The create form uses them to show live Jira projects and their issue types.
ld-issue-create-trigger takes a title, description, project key, issue type, and optional labels, then returns the new issue’s key and browse URL

On the LaunchDarkly side, the Jira integration form takes the issue-create URL, the Jira meta trigger URL (jiraMetaUrl), and the shared secret. Observability never calls Jira’s REST API directly. It calls LaunchDarkly, which calls Forge. In the product, Create Jira issue opens a dialog with project, issue type, title, description, and labels, then confirms with a toast linking to the new issue. If GenAI is on, Create with Vega passes your project key, issue type, and source IDs into the agent, which drafts the ticket and waits for your confirmation.

Create Jira issues from sessions and errors

From a session or error, open Create Jira issue. Choose the Jira project and issue type, review the title and description, and create the issue.

The Create Jira issue dialog with a Project menu set to "o11y findings (O11Y)", an Issue type of "Bug", a title, a description pre-populated with a link back to the error in Observability, a Labels field, and Cancel, Create with Vega, and Create issue buttons. — The Create Jira issue dialog, opened from an error, with live Jira projects and issue types.

A toast confirms that the ticket exists, with a link you can follow into Jira.

A toast reading "Jira issue created" with a chip linking to Jira issue O11Y-22. — A toast confirming the new issue, with a link to the Jira ticket.

After the issue is filed, a Jira chip appears in instance metadata. Click the chip to get back to the ticket later, without hunting through Slack or a screenshot folder.

An Instance metadata panel listing environment, service, version, URL, and timestamp, with a Jira row containing a link to issue O11Y-22. — The Jira chip in an instance metadata panel, linking back to the filed issue.

Create Jira issues with Vega

From a session or error, click Create with Vega. Context for the ticket, including project key and issue type, is prefilled in the Vega chat.

A Vega AI panel with a prefilled user message asking Vega to create a Jira ticket for an error group, including the Jira project key, issue type, source type, and source ID, and a reply saying that it is loading the relevant skill. — The Vega chat with the ticket context prefilled from an error group.

After you submit, Vega uses the jira_projects skill to load your Jira projects and the create_jira_issue skill to draft the ticket.

A Vega AI panel showing a drafted Jira ticket that has not been filed yet, with the project, issue type, labels, title, and a long description containing the error group, service, stack trace, and evidence. — A Vega-drafted ticket, with the evidence it gathered during the investigation.

Vega asks for confirmation before it files anything. After you confirm, Vega creates the ticket and shows a Jira chip, which also appears in the instance metadata box for later access.

A Vega AI exchange where the user says to go ahead and file the ticket, and Vega reports the filed issue O11Y-21 with its project, type, labels, linked error group, and a suggested next step. — Vega files the ticket after confirmation and returns a link to the new issue.

To learn more about this flow, read Create a Jira issue from a Vega investigation.

File tickets from alerts

Jira is also a notification destination for observability alerts. When an alert fires, a ticket can appear on your Jira board.

An alert's Notification settings with the Add notification menu open, listing Add members, Add Slack channels, Add webhooks, and Add Jira. — Jira in the alert notification destination menu.

Select the Jira project and issue type, and LaunchDarkly files an issue each time the alert notifies. Use the cooldown window and threshold settings to control how often LaunchDarkly creates those tickets.

An alert's Notification settings with a configured Jira destination, showing the Jira Alert Board project and the Bug issue type, and a note that LaunchDarkly creates a new Jira issue each time the alert notifies. — An alert with a Jira destination already configured.

To learn more, read Create Jira issues from observability data.

Know you are on track

You are on track when:

In observability, Create Jira issue populates the project and issue type menus
Creating an issue shows a successful toast with a chip linking to a real Jira ticket
Create with Vega drafts a ticket, waits for your confirmation, then returns an issue link

If something is off:

Secret mismatch between LaunchDarkly and Forge: Re-enter the LaunchDarkly API access token with the required role.
No create button: The API access token is not configured correctly, or the integration is not available on the account.

The win is watching a stack trace you were just looking at show up as a Jira ticket with its context still attached.

Next steps

A possible follow-on is two-way synchronization between Jira and LaunchDarkly, where Jira comments and status changes could reflect in the LaunchDarkly platform.

Wrap-up

Observability findings become Jira work through signed Forge webtriggers, and through Vega. Every finding links to action, and the evidence that made the ticket worth filing stays attached. As an intern working on this project, I am grateful I got the opportunity to contribute to something that sits between Observability and how teams actually track follow-up work. Thank you to my mentors and managers for guiding me throughout this entire design and implementation process, and for giving me the ability to take full ownership over a feature. Leaving this internship, I am most proud that I got to ship a real product surface end to end, and that I leave knowing how much trust and support it takes to do that as an intern. If you would like to connect or learn more, please reach out to Vaishnavi Panchal at vaishnavinpanchal@gmail.com, or on LinkedIn!

​The problem

​Why it matters

​Requirements

​How it fits together

​Create Jira issues from sessions and errors

​Create Jira issues with Vega

​File tickets from alerts

​Know you are on track

​Next steps

​Wrap-up