FireHydrant Reviews

My main use case for FireHydrant is automating incident response.

I used FireHydrant to automate incident response by leveraging its integration capabilities, as well as its customization capabilities to allow me to plug in my existing observability and telemetry tooling, and then configure the platform to respond based off of the incoming telemetry. That telemetry was then used to route between various teams and products inside of the enterprise to better response and to ideally remediate automatically if possible.

I believe one of the biggest impacts FireHydrant had on my organization was identifying ownership across services and products and then being able to track execution.

Tracking execution and identifying ownership improved things for my teams because nobody could hide behind a "I didn't know" or "it wasn't a problem" kind of response. As long as deep observabilities were in place, so logs, metrics, and traces, identifying where the issues were and then routing to those teams was critical. This also allowed me to take a data-driven approach in identifying where further R&D needed to happen across the product suite based off of what our customers were actually doing, bypassing biases from sales teams, development teams, and others.

I think the best features FireHydrant offers are the fact that the tool itself is completely moldable in a way where I could modify the transposers to allow me to integrate anything and everything with it.

The fact that the transposers existed was really what stood out to me in that they allowed me to integrate different systems. Instead of being shoehorned into a list of specific platforms, I could add anything I wanted. They're simple JavaScript. Take an input, massage its output, trigger the automations.

I think FireHydrant can be improved by being more AI first.

The overall configurability of the platform is quite robust, so wrapping natural language interactions around it would be really helpful. I'm thinking about almost replacing SRE teams. Many of the observability platforms are automating away the SRE roles. FireHydrant could probably work in that same world, noticing what observability platforms are doing and more about the why behind it, and then using that to enrich the incident response procedures.

I have been using FireHydrant at my previous company for about a year.

FireHydrant is deployed in my organization as a hosted solution by the vendor.

I can't recall which cloud provider FireHydrant used for hosting.

I would advise others looking into using FireHydrant to really think through the cultural impact a tool like that can have on the teams. Some teams can be very possessive and resistant to change as they might be a little more legacy in design. Other teams can be quite adoptive of it because it helps them protect the customer experience.

FireHydrant's AI capabilities in terms of governance and security are fine. However, FireHydrant's AI capabilities need to be treated with scrutiny regarding accuracy and reliability of output, and for the provider to be able to instill absolute trust in the user base is very difficult. I would think that allowing the platform to grow with human in the loop feedback with the goal of reducing that feedback over time because it got it right is the right approach.

I give FireHydrant an eight out of ten because it was recently acquired, and when a product is acquired, it brings in some potential concerns. I haven't seen how the acquisition has affected the product as I'm no longer with the company.

My main use case for FireHydrant was incident management, where it was plugged into our monitoring tool, DataDog. From that, we were able to trigger alerts that go into Slack channels, and from Slack channels, we can trigger and create incidents in FireHydrant. FireHydrant later helps us manage the whole incident lifecycle, including mitigation, the process, and it will also create the Zoom bridge and all of that.

FireHydrant helped me manage the incident lifecycle by providing multiple statuses for the incidents. If I recall correctly, there are incident created, mitigated, resolved, and other statuses. During the incident resolution process, we are basically reporting back our process into FireHydrant, which records that. Later, we use all this data to generate the post-incident review document, so this was one way we used FireHydrant.

We were also using FireHydrant Terraform provider to create all the necessary resources inside FireHydrant itself, which was something really valuable for us. Given that I am a senior DevOps engineer, I was managing the platform for multiple teams by mainly providing some Terraform modules that the team could use to create their services inside FireHydrant and to manage the whole incident lifecycle.

FireHydrant had a great impact on my organization, given we were using it consistently across all the incidents that we had. The incident reports were also consistent, and everyone was following the same template that was deployed inside FireHydrant.

I cannot recall that we tracked specific metrics, but our process was really simple. Whenever a team deploys a new service, we have a dedicated FireHydrant service attached to the actual service, creating a kind of one-to-one mapping between the service, the application, and FireHydrant services. On top of that, FireHydrant does provide metrics such as MTTR and other metrics that people follow as part of their incident management process.

I believe one of the best features FireHydrant offers is the Slack integration, which was really helpful, and on top of that, it was able to create Zoom bridges and a few other things that I do not recall anymore.

The Slack integration in particular improved our team's workflow during incidents, as Slack was our main communication tool. From Slack directly, we were able to tag some specific messages inside the incident Slack channel, and FireHydrant was able to gather the relevant Slack messages inside the incident. We were able to generate nice reports based on the conversation happening in Slack.

For improvements, I think I have nothing on top of my mind, given I am not using it currently, so nothing special to add.

Back then, I think there were some missing features in their Terraform provider, so that is the only thing that comes into my mind regarding needed improvements.

I have been using FireHydrant for about three years, but currently, I am not using it anymore as I used it in my previous company.

My advice to others looking into using FireHydrant is to properly define your services inside FireHydrant, ensuring that everyone follows the same processes and workflows to avoid inconsistencies between teams and services.

I did not use FireHydrant AI capabilities, so I have nothing to add regarding its governance and security.

I have not used the AI capabilities, so I have nothing to add regarding its accuracy and reliability of output.

FireHydrant was deployed in our organization in a public cloud environment.

We were using AWS, specifically the SaaS version of FireHydrant.

We did not purchase this via the AWS Marketplace.

I would rate FireHydrant around eight on a scale of one to ten because I think it is a great tool that does its job really well.

Public Cloud

Amazon Web Services (AWS)