# Turn every New Relic alert into a tracked Jira ticket > Every New Relic alert opens a Jira bug with the full context and a Slack heads up, then closes itself with the incident duration when it recovers. - Workflow type: code - Services: New Relic, Jira, Slack - Categories: Engineering - Published: 2026-08-07 ## What it does - Listens for New Relic alerts and opens a Jira bug the moment an issue fires, so nothing depends on someone spotting a chat message - Fills the ticket in for you with the alert condition, the affected service, the priority translated onto your own Jira scale, the time it started, and a link straight back to New Relic - Posts the new ticket to your Slack channel so the team sees the alert and knows exactly where it is being tracked - Closes the loop automatically: when the alert recovers, it finds the same ticket, moves it to Done, and leaves a comment recording how long the incident stayed open ## What you'll need - A New Relic account where you can add a notification destination to your alert policies - A Jira project you want the tickets created in, and permission to create issues there - A Slack workspace and the channel where alerts should be posted - The names your Jira project uses for priorities and for the Done status, if they differ from the defaults ## Prompt Build me a deterministic code workflow that turns every New Relic alert into a tracked Jira ticket, so no alert scrolls past in a chat channel without leaving a permanent record. Trigger it with a webhook. I will point a New Relic alert workflow at the webhook URL as a notification destination, so every incoming request is a New Relic issue event payload. Branch on the issue state in the payload. When the payload says a New Relic issue opened, run the open branch. When it says the issue closed, run the close branch. There is no judgement anywhere in this workflow, every field is a fixed mapping and the state field decides the path, so keep all of it in code. Open branch: create a Jira bug with Create Issue. Build the summary from the New Relic condition name and the affected entity, for example "New Relic: on ". In the description include the condition name, the affected entity or entities, the alert priority as New Relic reported it, the timestamp the issue opened, and a direct link back to the New Relic issue so whoever picks up the ticket can jump straight to the telemetry. Set the Jira priority with this fixed lookup on the New Relic priority: CRITICAL becomes Highest, HIGH becomes High, MEDIUM becomes Medium, LOW becomes Low. If the priority is missing or unrecognised, default to Medium. This next part is what makes the close branch possible, so do not skip it: write the New Relic issue id onto the Jira issue at creation time. Add a label of the form newrelic-, and also print the raw issue id on its own line in the description. The close branch finds the ticket again by that label, so the id has to live somewhere a JQL query can match exactly. Then post the ticket to Slack with Send a Message, to a channel I will configure. The message should carry the Jira issue key and a clickable link to the ticket, plus the condition name, the affected entity and the priority, so the channel sees both the alert itself and where it is now being tracked. Close branch: when the payload says the New Relic issue closed, find the matching ticket with Search Issues (JQL), querying on the label that holds the New Relic issue id, something like labels = "newrelic-" scoped to my Jira project. Take the most recently created match. Move it to Done with Do Transition, resolving the transition by its name rather than hardcoding a transition id, since those ids differ from project to project. Carry a comment on that transition recording how long the incident stayed open, computed as the difference between the opening and closing timestamps in the New Relic payloads and written in plain terms, for example "New Relic issue closed after 2h 14m", along with the closing timestamp. If the transition will not accept a comment, add it separately with Add Comment. A few fixed guards, all deterministic. Before creating anything on the open branch, run the same JQL lookup first, and if a ticket already exists for that New Relic issue id, skip creation instead of opening a duplicate, because webhook deliveries can retry. On the close branch, if no ticket matches the issue id, post a short note to the same Slack channel saying a close event arrived with no matching ticket, rather than failing the run. If the matched ticket is already in Done, leave it alone. ## How to customize - Change the Slack channel, or send high priority alerts to one channel and everything else to another - Adjust the priority mapping so New Relic priorities land on whatever priority names your Jira project actually uses - Switch the issue type from Bug to Incident, change the target status from Done to Resolved, or only raise tickets above a certain priority ## FAQ ### Will it create a duplicate ticket if the same alert fires twice? No. Before opening anything, the workflow looks for an existing ticket carrying that New Relic issue id and skips creation if it finds one. Alert notifications sometimes get delivered more than once, so this guard keeps your backlog clean. ### How does it know which ticket to close later? When the ticket is created, the New Relic issue id is written onto it as a label and repeated in the description. When the alert recovers, the workflow searches Jira for that exact id, which is why it always reconnects the closing event to the right ticket. ### What if the alert closes but nobody actually fixed anything? The ticket still moves to Done with a comment showing how long the incident lasted, because the point is an auditable trail of every alert. If you would rather have recovered alerts land in a review column instead, you can change the target status when you set this up. ### Can I use Microsoft Teams or another chat tool instead of Slack? Yes. The Slack step is just the notification at the end, so you can swap it for another supported chat tool without touching the ticket logic. ### Do I need a specific New Relic plan for this? You need to be able to add a notification destination to your alert policies, which is part of standard New Relic alerting. If your alerts can already reach email or a chat channel today, they can reach this workflow. Use this prompt in General Input: https://www.generalinput.com/prompts/turn-every-new-relic-alert-into-a-tracked-jira-ticket