When FireHydrant originally launched our Jira Cloud and Jira Server integrations, we did not support custom fields. This prevented customers who rely on Jira epic ticket types or other custom required fields from getting full value from our Jira integrations. That has changed with the launch of Jira custom field support. We now support the most common type of Jira epic tickets and field-level mapping of Jira custom fields with FireHydrant incident data.

When an incident happens, most organizations have a way of identifying all affected services. The trouble is, it’s often a human-centered process that depends on the knowledge of key individuals or manually updated documentation. There might be a version in your alerting tool, a version in your corporate Wiki, and a different version still in your team’s head.

When it comes to learning from incidents, your tools should adapt to the way your organization works. Many of you conduct your retrospectives in rich-text document editing tools, like Google Docs. That’s why we’ve introduced the option to export your retrospectives to Google Docs. Retrospective export to Google Docs can be automated as part of your incident management process with a Runbook step.

FireHydrant captures your incident, from declaration through remediation, and gives you a framework to run your retrospectives. But retrospectives are only as effective as their inputs. Now we're delivering a better way to learn from and analyze retrospectives by guaranteeing consistent, structured, and sufficient data from your team.

When incidents inevitably occur in your software stack, managing them well could be the difference between losing customers and building trust with them. In this article, we’ll give you and your team some best practices on how to prepare for managing incidents. It’s crucial to define service ownership, a declaration process, and practice all of it. With a little planning now, you'll be able to cut your incident response time drastically.