Since the beginning, we’ve wanted to make it faster, easier, and even a joy to respond to incidents. We’ve had the typical components of incident response for a while, but orchestrating them together was a manual task by our users. Today we’re marrying together all the features already available in our incident response tool into our newest release: Runbooks.
Why did you build this?
Airplanes have a little booklet in the cockpit that provides a simple checklist on what to do for mundane to the extreme situations. We built runbooks to help people respond to incidents in a more streamlined way, similar to the book pilots have access to. We want you to focus on what matters: resolving the incident. Creating Slack rooms, emailing CEOs, drafting JIRA tickets are significant tasks that we wanted to take off minds of responders when it’s 6 pm on a Friday. We also believe runbooks should guide, not prescribe.
What are they?
Runbooks are our way of defining a list of steps that need to happen when an incident occurs. If a SEV1 incident is declared, a myriad of steps might need to be taken. You may need to inform customers, email executives, and create a Slack channel. With runbooks, we’ll perform the steps you’ve customized instantly.
We’re allowing you to define runbooks for all types of scenarios. Whether it be for a SEV1 incident or restarting one of those pesky services with a memory leak, you can define the steps necessary for any task you need to take.
We’re also providing insights you didn’t have before. FireHydrant allows you to provide feedback about any runbook you’ve defined when used. We can surface runbooks that are maybe outdated, inaccurate, or frequently used.