Too many of us are still playing whack-a-mole when it comes to incidents: an incident is declared, the on-call engineer is paged, the incident is resolved and then forgotten — until next time. It’s time to start thinking in terms of proactive incident management, not just reactive incident response.

At a going away party from a job I was leaving a few years back, my VP of engineering told a story I didn’t even remember but that I know subconsciously shaped how I viewed my role on that team: Toward the end of my very first day at the company, there was some internal system issue, and with pretty much zero context, I pulled out my laptop, figured out what was going on, and helped fix the issue.

Inflation is running rampant, the world stage is unpredictable, and what’s happening in the U.S. markets has been dubbed the “tech wreck.” A common theme I’m hearing come up in conversations across industries right now is value — we’re all looking to maximize every dollar spent, every hire made, every hour logged. For a lot of companies, this means looking at processes and tools with a critical eye for not only cost savings but also cost avoidance.

Previously, FireHydrant supported video collaboration tool integrations for Zoom and Google Meet. In response to customer asks, today we are pleased to introduce our new Cisco Webex Meetings integration for all paid plans. With the new integration, teams can automate Webex bridge creation as part of incident response.

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.