True reliability takes into account all of the services that exist in your software environment — which is why it can get so complicated. An ecommerce site, for example, might have services that update current inventory in near real time, process payments in the shopping cart, trigger email receipts to send, kick off fulfillment orders, etc. And if one of these services isn’t operating at its best, that can mean money — and in some cases, customers — lost for the company.

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.

Engineering teams can now manage incidents in Microsoft Teams. You’ll have the consistent process and automation of FireHydrant right in the messaging tool you use every day. Effectively run through the entire incident response lifecycle: declare and manage incidents, collaborate with stakeholders, and resolve incidents faster when you integrate FireHydrant with Microsoft Teams.

We envision a world where all software is reliable, and today we’re making that vision more of a reality for small teams. Available today, our new Free Tier helps smaller teams wrangle their reliability challenges with our enterprise-grade Incident Management, Service Catalog, and communications products. Our new package also has every feature that makes FireHydrant great with generous limitations.

What comes to mind when you hear the term 'incident commander'? You are not alone if you think about fancy, tri-cornered hats, well-polished shoes, and a uniform weighed down by medals. The roles of incident commander, incident manager, or technical escalation manager have been typical in large organizations but are gaining popularity in smaller companies. For the purposes of this article, we will use the term 'incident commander,' but any of the above titles could work.

Keeping track of what all that you need to do to mitigate an incident is crucial. And if you’re an Incident Commander, you also need to keep track of what everyone is doing. This is why we’re excited to share a new experience in Slack to create and manage all tasks in an incident.