FireHydrant can create tickets in Jira for each of your incidents, with linked tickets for follow-ups to prioritize after the incident. This way, all actions proposed during an incident are tracked in your existing project management workflows for estimation and scheduling.
All steps in this document are required unless otherwise noted.
- You'll need to be an Owner in FireHydrant to configure integrations
- You need a service account/user in Jira with the following permissions:
- Project Permissions
- Browse Projects
- Issue Permissions
- Assign Issues
- Close Issues
- Create Issues
- Edit Issues
- Link Issues
- Move Issues
- Schedule Issues
- Other Permissions
- Read all Jira ticket types to be used with FireHydrant
- Read all Jira fields and custom fields to be mapped in FireHydrant
- Project Permissions
FireHydrant recommends using a generic Jira Cloud service account rather than an individual named user to avoid problems if the named employee were to depart the organization.
Ensure you are currently logged into Jira as the service account and not in your personal account, otherwise the connection will be established with your personal account.
- Go to the Integrations page and search for the Jira Cloud integration. You can also view our Jira Marketplace listing, which lists the same instructions.
- Click the '+', and then click Authorize Application. This will take you to Jira where you can authorize FireHydrant's application. Follow through the on-screen prompts.
To see updates to your tickets reflected in FireHydrant, you must configure an outbound webhook from Jira back to FireHydrant.
- Once you finish installing Jira, you should be taken back to the Jira integrations page, where you should see a Webhook URL. Copy this URL.
- In Jira, configure a Webhook listener for FireHydrant using the copied URL. This is under Settings > System > WebHooks. On this screen, click "+".
- Set this webhook for the projects you plan to use with FireHydrant (or all issues), and then check the Issue created and Issue updated boxes.
When creating Incident tickets via Runbook step, the Reporter of the Jira ticket will be set to the default authorized user on the account (e.g., whichever account was logged in when setting up the Jira integration).
However, for individual Follow-Up tickets created during incidents, FireHydrant will try to set the Reporter to the person who created the Follow-Up. To correctly do this, users must authorize FireHydrant to create tickets as them in their settings. If users do not link their Jira and FireHydrant accounts, they can still create Follow-Ups, but FireHydrant will fall back to the default authorized user as the Reporter in that instance.
To connect FireHydrant and Jira accounts, each individual will need to:
Go to their User Settings and click on their organization.
Click Link on the Jira Cloud row.
The next page that opens gives you the option to let FireHydrant access your Atlassian account. After you click Accept, FireHydrant can correctly associate action items and tickets that you have created with your user ID in Jira Cloud.
Once a user has linked their FireHydrant account to Jira account, creating Follow-Ups linked to Jira projects will set the user as the Reporter. Subsequently, the user will need appropriate permissions for the Jira project in which they're trying to create a ticket.
Before using the Jira integration, you'll need to configure a mapping for each Jira project you'd like FireHydrant to interact with so it knows what types of issues, issue states, or relationships to use when creating Jira tickets.
- From the Jira integration page in FireHydrant, scroll down to the Projects section and click '+ Add Project.'
- A modal will pop up for you to select which Jira project to configure. Once you've chosen one, the project will be created, and you'll be taken to the project settings page with the following tabs.
These settings will be necessary to create incident tickets in this Jira project but can be ignored if you only plan to use this project for Follow-Ups.
- Incident Default Issue Type - This is the issue type we'll use for incident tickets. Many FireHydrant users may create specific "Incident" issue types in Jira.
- Milestone Mappings - These are the Jira ticket statuses we'll use in Jira to correspond to the FireHydrant incident's Milestone.
- Any Active incident in FireHydrant corresponds to the Started, Detected, Acknowledged, Investigating, Identified, and Mitigated milestones.
- Any Inactive incident in FireHydrant corresponds to the Resolved, Retrospective Started, and Retrospective Completed milestones.
These settings will be necessary for creating Follow-Ups in this Jira project but can be ignored if you only plan to use this project for incident tickets.
For example, many FireHydrant organizations will have a specific "Incidents" project where FireHydrant creates incident tickets. Then they may configure separate projects for different engineering teams to create Follow-Ups.
These are the available fields:
- Default follow-up relationship to incident ticket - This is the type of relationship to associate the new follow-up ticket to your incident ticket if one exists. The relationship originates with the new task (outward relationship in Jira parlance).
- Follow-up default issue type - The type of issue we'll create in your Jira project for Follow-Ups
- Follow-up status mappings - Maps the FireHydrant Follow-Up status to selected Jira issue statuses. FireHydrant's terminology uses "Open," "In Progress," and "Done" to refer to a ticket's overall state.
Jira is complex and highly configurable, so sometimes custom mappings need to be made between FireHydrant's incident fields and Jira's ticket fields.
You will need to configure field mappings if you have any custom required fields, otherwise FireHydrant will not be able to create tickets in your project(s).
To learn more about field mapping, visit Jira Field Mapping.
To avoid unexpected problems, before you delete a configured Jira project, ensure that you have accounted for any Runbook steps and linked incidents and action items that reference the project.
Go to the Jira Cloud integration settings to remove a configured Jira project from the integration. Under Projects, click Edit next to the project you wish to remove, then select Delete Project tab and then Delete permanently. Confirm the action.
For any operations that require creating a Jira ticket, FireHydrant will use the Project selected (e.g., in the Runbook step, in the dropdown when creating a Follow-Up, etc.).
But if those don't exist or are not specified, FireHydrant can/will fall back to a Default Project you configure. In addition, if you are creating Follow-Ups via emoji in Slack, this Default Project will also be used.
This can be configured in Settings > Ticketing settings > Default project.
Like Alerting & Monitoring providers, Jira has "alert routing" capabilities, which allow FireHydrant to take action on inbound webhooks from the Jira instance automatically.
This allows, for example, the creation of Jira tickets in certain projects or matching specific parameters to start incidents in FireHydrant or notify certain Slack channels automatically.
To learn more about how it works, visit our Alert Routing documentation. Below is an example showing a typical use case where any ticket created in an "Incidents" project automatically starts an incident on FireHydrant.
The table below shows the available parameters you can filter on and how to access them via Liquid templating.
|Jira Webhook Body
|Jira: Status Category
|The key of the status category for the issue's status
|The Jira status of the created issue.
|Jira: Project Type Key
|Project type key of the project the issue was created in. For example,
|Jira: Project Key
|Key of project issue was created in
|Jira: Project Name
|Name of project issue was created in
|Priority of created issue
|URL to alert page in PagerDuty
|Jira: Created At
|When the ticket was created in ISO 8601 formatted datetime. For example:
|The Summary field within Jira (usually the title)
|Jira: API URL
|The URL for this specific Jira ticket included as the
self parameter. Usually comes in the format of:
|The Jira issue ID. Number is generated and assigned by Jira on issue creation.
The following table maps our overall Alert Routing mapping object - these parameters are standard across all Alerting/Monitoring integrations and are derived from above parameters.
|Jira Webhook Body
|The same as Jira: Summary above.
|The same as Jira: Description above.
|Maps to nothing for Jira.
|If the ticket is
done in Jira, then this parameter is
resolved. Otherwise, it is
|Alert Associated Infrastructure
|Maps to nothing for Jira. There is no way to associate Jira projects with specific Catalog components currently.
Updated about 1 month ago