Changelog

Anyone who’s declared a FireHydrant incident has more than likely declared it from slack - in fact 80% of incidents created originate in Slack. The vast majority of interaction with FireHydrant comes through Slack, and many of our customers do everything from Slack, only touching the web app if there is a slack outage or incident. Today, we’re announcing some improvements to the slack experience to make interacting with FireHydrant through slack operate with the speed of the terminal and the ease of use of a fully functional user experience.

Modals for Help and for Command Launch

To support new or infrequent users using FireHydrant, we’ve made the FireHydrant help experience a modal where you can select any command to learn more about it. Not only will we help you understand the nuance of what certain commands will do, we’ll also give you an easy way to launch it as soon as you’re sure it’ll do what you want it to. We’re also shifting the /fh command to bring up the same modal, which gives direct access to a broader list of commands, making it easier to run the command you want, faster. To test this run /fh help or /fh in any slack instance connected to FireHydrant today.

New Incident Declaration and Edit Experience

In addition to the big changes we’re making to your Slack experience, we’re also giving you greater control over the fields that appear in your declare incident form, in order to help your team declare an incident more quickly. Administrators will now be able to designate fields as “required,” “visible,” and “additional” in field configuration, controlling whether they appear by default (required or visible) or require addition to the form by the person declaring the incident (additional). In parallel, we’ve changed the experience when editing the incident in slack to be more closely aligned to the declaration experience. Now, when running /fh edit the experience will mirror the /fh new experience with field behavior.

Updating Status Pages

Now that we have a command that helps us edit incident details, we’re taking the opportunity to focus the /fh update command on updating external communications - your status page. This will allow you to change the milestone, and update the information available on your status page, as well as select status templates directly through slack. As part of this, we will be moving the ability to move and add services, to directly within /fh service or /fh add service.

Adding Catalog Entries

And as the last change in our large slack UX update, we’ll be making it easier to add things to your service catalog using the /fh add {catalog entry} command. This will allow you to add services and functionalities in a single command, as well as search all items in a single grouped drop down.

We’re really excited for you folks to try these new commands out and see how much they speed up your incident workflow. To get a feel for the new behavior, just run /fh help from any slack channel connected to FireHydrant. Happy Firefighting!

For you folks who use Jira, it’s probably the source of truth of, well, everything that’s being worked on within your product and engineering organization. From compliance to actually doing work, Jira is a core part of getting anything done, including responding to incidents and making sure those pesky follow ups get done post incident. If your org uses Jira, we have good news for you, because today, we’re announcing some improvements to our Jira integration.

Bidirectional Sync

Most teams that are using Jira and FireHydrant create a ticket in Jira via hydrant that serves as the hub for subtasks, related tickets, and others, usually automated through a Runbook step. However, once that Jira ticket was created, FireHydrant and Jira could sometimes have different representations of the state of that ticket, depending on the last updated system. Now, whenever any standard fields of that ticket are updated (summary, description, and labels), those fields will update in both Jira and FireHydrant. The work doesn’t end there either - we’re working on expanding the fields that will be synced across Jira and FireHydrant (specifically priority and assignee) and will keep you updated as those items launch.

Improved Field Mapping Experience

Anyone who’s set up Field mapping between Jira and FireHydrant (or hopefully by now, Asana and FireHydrant) know that mapping fields between the two systems can be a little painful, especially when there’s conditional logic on what the value of that field should be. Fortunately, our design team got ahold of the UI, and have made it significantly easier to understand which fields in your ticketing system are mapped to FireHydrant custom fields, and under what conditions will a particular value will be set. FireHydrant will continue to “own” the field in Jira, so there are no behavioral changes here, just increased ease of use!

To learn more about the Jira Integration in FireHydrant, try it out by going to Settings > Integration List > Jira and clicking the edit icon. From there, you can re-authorize the connection to setup bi-directional syncing (we'll update our connection to give FireHydrant the "manage:jira-webhook" scope). You can also checkout the newest version of field mapping in the new "Field Mapping" tab to update your existing field mappings.

If you’re using Asana, it’s not a stretch to say you’re probably using it to keep track of your incidents and follow ups too. Wouldn’t it be a meditative experience if your incidents automatically synced between your incident management tool and Asana? Well, take a deep breath because now they do thanks to our new Asana integration.

Incident Tickets

One of the most common ways that teams start tracking incidents is by creating tickets in their task-tracking system. Teams use these incident tickets as hubs for creating subtasks, related tickets, and more. For Asana, as well as other ticketing integrations in FireHydrant, this is easily automated through a Runbook step. Teams can configure a runbook step that will create an incident ticket with data populated from the incident. Liquid templating makes this runbook step incredibly powerful, allowing users to add almost any piece of data from an incident to the title or body of the ticket.

Follow-Ups

In addition to tracking incidents with a ticket, most teams rely on their ticketing system for tracking follow-up work from the incident. When using Asana with FireHydrant, you can easily create subtasks for the incident task from either Slack or the FireHydrant web app.

Field Mapping

To keep your data in Asana in-sync with your incident, you can create field mappings for any of your custom fields in Asana pulling in FireHydrant data like the incident name, severity, and even any of your custom fields in FireHydrant. You can even send custom values along as text, and you can also leverage FireHydrant’s liquid syntax to send detailed information about an incident. You can also build conditional logic to populate fields with different values based on the state of your incident. For instance, you might want to set the value of a custom select in Asana if your incident is a SEV1 or SEV2 but leave it blank if it’s lower than that. Conditional custom fields make that all possible. To learn more about our Asana integration, try it out for yourself by connecting your Asana project to FireHydrant. Dive deeper by reading more about setting up our Asana integration in our docs.

Updated Retro PDF

One of the most common outcomes of a retrospective is to share data, learnings, and next steps with stakehodlers across the team. One of the easiest ways to share that information quickly is to turn your retro in a PDF. And today, we're excited to share a new and improved Retrospective PDF export which better organizes information for your readers and includes the important data that they need.

Milestone Table in Retrospectives

One of the primary advantages of using an incident management tool is to reduce the toil involved with building a timeline of activity in an incident. And while FireHydrant provides a robust set of tools to help you understand the timeline of your incident, today we're adding another tool to help you and your team make sense of what's happened in an incident: a table of all the milestones in an incident with the ability to show time duration either from the start of an incident or between milestones.

Time Since Note or Update

One of the more heavily used runbook step conditions is the "Time Since Last Note." This allows teams to setup automations and reminders to have team members provide updates about the incident. We have updated this condition to now take into account any updates that have been provided, including posts from /fh post and /fh update. With some upcoming releases, we'll also be simplifying these commands to consolidate on a single update-style command and modal experience. In preparation of that change, any text updates will now meet the "Time Since Last Note" condition. If you have specific workflows that depend on only having Notes update the condition, reach out to our team about being opted-out of the change.

Bugs and Fixes

• We fixed a bug with Zoom authentication causing issues with runbook step execution.
• We fixed a bug with sharing retrospectives across organizations in a multi-organization setup.
• We fixed a bug with subscriptions on new Status Pages

Minutes matter when it comes to incidents, and getting the right people in the room (or, let’s be honest, Slack channel) is essential to a seamless incident management experience.

So today, we're rolling out a new command to our Slack integration to make paging teams and individuals dead simple. While FireHydrant has supported service and functionality based paging for a long time, we’ve heard from customers that they also need a simpler paging mechanism for getting the right people into the incident response. The new /fh page command allows teams to do just that: you can now send a new page to any user, team, or escalation policy or even add responders to an existing page for the incident.

This simplified approach to paging allows you to send a page to any user or team-like entity in your 3rd party alerting tool. In Pagerduty, you can reach out to users or escalation policies, and in Opsgenie, you can reach out to users or teams. Splunk On-call currently only supports paging escalation policies.

When sending a page, you can craft a specific message and description to help the responders know what kind of help you’re looking for. FireHydrant will also send along the Slack channel where the page was initiated so that responders can quickly jump into the channel for more context.

If an alert or page has already been connected to the current incident, you’ll also have a chance to add new responders to an existing page so that you don’t need to duplicate alerts or incidents in your 3rd party tool.

Along with this new command, we’re also introducing a new in-channel alert message that tracks connected alerts or pages. This new message tracks the state of the alert– triggered, acknowledged, resolved, etc.–as well other details like who has been notified and who originally sent the page. This new message helps you stay in the incident channel instead of hunting down the stage of the page in another system. Additionally, this new message works across all connected alerts in an incident, including the new page command, pages created from /fh page service and /fh page functionality, as well as any manually connected alerts.

To learn more about paging in FireHydrant, try it out by running /fh page or read our updated docs.

Saved Views in Analytics

Many teams depend on tracking key analytics for their specific teams or services in FireHydrant. And while our analytics tooling has provided an easy way to get those insights out of the box, we heard that it was cumbersome for folks who had very specific dashboards they like to review regularly. The new Saved Views in Analytics now supports saving your filters to easily accessible dashboards that you and your team can now regularly review.

In addition to supporting Saved View in Analytics, now all Saved Views on FireHydrant are more powerful because they can be set to private or public, meaning you won’t clutter up your team’s shared workspace with a bunch of saved views that only you use. This is now available for Incident Saved views as well as any Catalog pages.

View Fields on Incidents Page

When viewing a list of incidents, there are a plethora of ways that any user might want to be looking at those incidents. To make the Incidents page even more flexible and useful, we added in a new View Fields feature to allow users to customize what they are seeing for each incident. Any data associated with an incident can now easily be shown within the list view, including custom fields. View Fields settings are saved locally within the browser, so the next time you visit the Incidents page, you’ll see the same fields you viewed the last time.

Bugs and Fixes

• We fixed a series of issues around resetting access tokens in our integrations including Zoom and Jira.
• We added the ability to revoke invitations within the invitations page.
• We fixed an issue where deleting values in fields was breaking Incident Types
• We fixed an issue with discarded FireHydrant users not being able to open new incidents in Slack.

Today, we’re launching a significant upgrade to our public status pages. As we’ve spent time with our customers, we’ve learned about not only how status pages represent their brand at some of their most critical moments as a business but also how status pages can be a key part of how teams communicate internally with their leadership and other stakeholders. We learned overall that status pages are a critical communication tool for teams responding to incidents, and so we decided to make some improvements.

To begin with, our team set out to improve the look and feel of our status pages. We wanted to make sure that in those critical moments, a team's brand would be complimented by the status pages. To that end, we created a status page experience that is both simple and elegant to allow elements like an organization’s logo and messaging to be front and center. We’re also introducing dark-mode for status pages, letting your users pick a theme and reuse that theme whenever they visit your page again.

In addition to a redesign, we introduced a few new important features. Firstly, we added the ability to show a 90 day view of any component’s history. Because FireHydrant’s status pages are driven by the service catalog and tied into your incident response, we’re able to show a simple histogram of all incidents where a given component has been marked as impacted. Users can use the histogram to easily navigate to individual incidents for that components.

Additionally, we’ve added the ability to group components together to create synthetic status and histories for a set of components. You can easily group components together for each status page that you maintain, allowing you to create unique groupings based on the audience of your status page. You can also create subgroups within a group to add further scaffolding to your components to help users understand a large set of services or functionalities. Groups will roll-up history, showing any incidents for a given day within the group and using the highest level of impact for the histogram (i.e. if any incident in the group is marked as Unavailable, the group will show Unavailable for that day).

And finally, to help teams who are building status pages for internal audiences, we’ve introduced the ability to add any data collected during the incident to the incident page on the status page. Now, when your users visit the page for a specific incident, they can see any fields that you’ve picked to show for incidents including any custom fields. Picking the right details to show per incident is critical, so you can configure which fields are shown per status page that your create in FireHydrant.

Starting today, all new status pages created in FireHydrant will have access to this updated experience. You can also choose to migrate any existing FireHydrant status pages to the new experience by selecting “Enable the latest version of Status Pages” when editing your status page settings. To learn more, check out our updated docs.

Editing Retrospectives during an Active Incident

You asked, and we’ve answered: users can now edit a retrospective during an active incident. Oftentimes during an incident, you’ll already have an idea about specific questions you want to answer for the retrospective. Now, during an incident you can easily toggle to the retro view to start filling in those details as they emerge. To try it out today, navigate to any active incident (or open a Gameday incident), and open the contextual menu in the top right corner and click “View Retrospective.” And to get back to the incident, follow the same steps but click the “View Incident” button.

Updated Severities Matrix

The severities matrix in FireHydrant is a powerful automation tool for organizations with a service catalog. Users can simply select the condition of a given catalog item (Operational, Degraded, and Unavailable are our defaults) and the associated incident will automatically receive a severity that you have set up. And now we’re shipping some ease-of-use changes to the matrix interface to help teams automate their service catalog. Additionally, we’ve moved component conditions to their own editable UI so that you can easily update those apart from the severities matrix.

🐛 Bugs and Fixes

• We added search to the Integrations page
• We added the ability to search PagerDuty services when importing into the service catalog
• We fixed an issue with refreshing authentication tokens across several integrations
• We fixed an issue with some users not being able to resolve incidents from the quick action buttons in Slack.
• We fixed an issue with custom fields not showing up in Multi-Step modals in Slack
• We improved our user profile page by removing the need to enter your password when updating your name.

Today we're releasing Multiple Organizations, a powerful new way to manage your teams, business units, and security clearances all from within the same account.

Multiple Organizations, or Multi-org, allows you and your teams to run siloed instances of FireHydrant, keeping incidents, runbooks, and all of your incident management processes separate from other parts of your organization.

With Multi-org, users who are a part of multiple organizations can easily switch between different organizations all from within a single Slack workspace as well as the FireHydrant web app.

To get started with Multi-org, reach out to our support team today! You can learn more about multi-org support in our blog post.

Today we're releasing custom fields, a powerful new feature that empowers you to tailor FireHydrant to your organization's specific needs and capture essential incident details.

Custom fields help you track critical states, involved parties, resolution specifics, affected services, messages, and more — almost anything you want! — all aligned with your unique workflows.

You can create text fields as well as single select and multi-select lists. You can also require custom fields on incident declaration to make sure your team is capturing exactly the right data. Any custom field can be filled out from Slack, the web interface as well as our API, and they can be used in our liquid templating for notifications and runbook steps.

To get started with Custom Fields, add your first custom field on the Incident Settings page. Be sure to check out our docs to learn how to fully leverage your custom fields.

Create your own Slack commands to run Webhooks Are there key actions that your team needs to be able to take in other systems when responding to an incident? With our new webhook integration, you can build custom Slack commands for the FireHydrant bot that will call an external service via a webhook that you configure. You can use it to restart services, retrieve information about a current deployment, or just about anything you can dream up and build or connect via webhooks. To try it out check out our docs page for creating webhooks and Slack command extensions or even our example GitHub repo.

This new feature is experimental, and we welcome any feedback you have! Send us an email to support@firehydrant.com with your thoughts.

Bugs and Fixes

• 🎨 We updated our system emails to match our new UI design.
• 🎨 We updated the sidebar of the command center to be easier to reduce clutter.
• 🎨 We updated the design of our tasks and follow-ups to make it easy to understand and take a next step for each.
• 🔨 We updated the milestone quick filters to use a more legible name.

New Layout and UI in Command Center During an incident, it’s essential to have the most critical information readily available and provide updates as seamlessly as possible. That’s why we’re excited to release incredible improvements to the page that matters most: our incident command center.

Our incident command center has a new header that simplifies and condenses information, allowing you to update the title, severity, and milestone immediately. The incident details sidebar got a refresh, making it easier to scroll and read the most important facts about your incident. And finally, the incident timeline got a revamp, simplifying the information included with each item and highlighting the events with unique content. Check out the updated command center today by navigating to any active incident in FireHydrant.

Open Tasks and Follow-Ups with Emoji Reaction in Slack Has someone ever posted a really good Slack message describing some follow-up work for an incident? Starting today, you can just add an emoji reaction to that message to easily create a new task or follow-up. The emojis are configurable too, meaning you can use whatever custom emoji you like to easily create tasks and follow-up tickets for your team.

Bugs and Fixes

• 🔨 We added the ability to attach runbooks from within a retrospective.
• 🔨 We updated the landing screen for Analytics when a user doesn’t have access
• 🐛 We fixed a bug where Jira ticket priorities were not syncing correctly
• 🐛 We fixed an issue with our mobile navigation bar
• 🐛 We fixed an issue with timeline content not wrapping correctly
• 🐛 We fixed an issue with runbook attachment types being labeled incorrectly

Declare Incidents from Jira Tickets

• Using Alert Routes, you can now automatically open incidents or alert Slack channels from Jira tickets. For teams that leverage Jira or Jira Service Management for recording initial details about an incident, you can now set up those tickets to automatically open an incident with all the details pre-populated. With the power of Alert Routes, you can continue lowering the barrier of opening incidents by making it as easy as creating a Jira ticket.

Edit Zoom and Google Meet Links

• Now you can update the links for a Zoom or Google Meet video call just like other links that users have added to an incident. Did someone already start a call that everyone joined? No problem: you can just change the link in FireHydrant and responders will see the new link when joining.

Updated Change Events Table

• Change events are now a bit cleaner and easier to work with during an incident. You can quickly scan any attached change events and quickly update their relevance to the incident at hand. Check out the updated table today by visiting the change events tab in any active incident.

Bugs and Fixes

• We fixed an issue with the filtering mechanism on the Incident list view
• We updated ‘matches_all’ tag matching strategy to match even when additional tags are present.
• We added checks to better suppress duplicate messages in the same channel.
• We added a check on the Incident list view to convert any legacy formatted URLs to automatically convert to the new format to make it easy to bring any bookmarked URLs into the new UI.
• We fixed an issue with required fields being skipped when a milestone was set manually.

At the heart of a tool like FireHydrant is the ease of mind that you get from automating your processes. Need to remind your responders to post updates to the status page? Set up a runbook step and it’s good to go. But in order to keep that process running smoothly, it’s important to know who exactly has access to update that process. Giving your team just the right level of access to your incident management tool is critical to maintaining that ease of mind and high-degree of confidence about your team responding to incidents.

And if you are building a secure and scalable incident management process for your organization, Role-Based Access Control is one of the most important tools that allows you to define and assign roles to individuals involved in incident response. It ensures that the right experts have the appropriate access to address incidents swiftly and effectively, and that all of your stakeholders have the right access to status pages, incident summaries, and retrospective reports.

Today, it’s even easier to set-up FireHydrant with a major update to our Role-based Access Controls. In addition to the two core roles that FireHydrant has always offered (Owner and Member), we’re introducing two new roles to help you give your team just the right level of access to the platform:

• Viewer: the new Viewer role allows you to grant view-only access to incidents in the FireHydrant platform. Just like unlicensed users, Viewers can join Slack channels and view status pages, but they can also log-in to FireHydrant to view incidents and the Service Catalog.

• Collaborator: the updated Collaborator role is designed for the majority of your users who are involved with responding to incidents but don’t need to manage anything about the process like Runbooks, Severities, or the Service Catalog. These users can have assigned roles in incidents, post updates and make edits on an incident.

Using these two new roles, you can now give your team members the appropriate access for their needs without worrying about changes to your core workflows and settoimgs. Access to important configuration like Runbooks, Incident Types, Service Catalog, and more, remain unchanged for your managers and admins in Owner and Member roles. Now, you can assemble the right teams for your incidents with confidence in the security of your data and, importantly, can rest easy that your well-defined processes will continue to guide Incident Responders towards resolving incidents quickly.

To get started with these new Roles, you can easily update individual roles in the FireHydrant web app or via your IDP using our SCIM API endpoint (docs). Read more about our roles here in our documentation.

UI Refresh now Generally Available

• Over the last few months, we’ve been re-working our web application’s interface to make responding to incidents even easier (and dare we say delightful?). When we announced the beta last month, we included some core experiences like a new dashboard, updated tables with easier search and filtering, and an updated navigation. Since then, we’ve added a bunch of new features to the beta including a notification center, a command bar, and new views for your tasks and follow-ups. To check out the latest UI, just login to the FireHydrant web app.

Add Groups to Slack Channels

• When adding users to a Slack channel, you might not know a specific person who should be involved but do know a Slack user group that should be included. Now, you can add user groups (@sre-team for instance) as part of the "Invite Users to Channel" step in runbooks. To start using groups in your channel invitations today, be sure to re-authorize your Slack app by visiting this link.

Bugs and Fixes

• We fixed an issue with incident filters using OR rather than AND logic.
• We fixed a bug with responding teams being removed from services and functionalities.
• We fixed a bug that prevented some services and functionalities as being marked as impacted.

Today, we’re excited to launch Private Incidents into GA. We’ve spent the last year learning alongside customers to deeply understand the needs around running high-risk incidents. We’ve identified some critical areas of access control and automation, ensuring that teams can run any type of incident with lowest friction possible.

Access Control

One of the most important aspects of private incidents is making sure that only the right people can see things like PII, financials, or other sensitive data. Private incidents allow you to restrict access to an incident in Slack and in FireHydrant. Have responders who should always be in private incidents? No problem: you can set them up with global access to private incidents. Private incidents create private Slack channels by default and only users with access will see the incident in FireHydrant.

Converting Public Incidents to Private

In order to promote a healthy culture of reliability, many teams encourage a very open policy around declaring incidents. Did someone see something that might have looked like an incident? Just open one up for investigation.

But in a culture where many incidents are opened, it means that some potentially sensitive or private incidents get opened as an initially public incident. In FireHydrant, any public incident can be easily converted to private and a new private Slack channel will be created. During conversion, all Runbooks will stop executing so sensitive data isn’t accidentally sent to a status page or an all-company email. Users who are converting an incident to private also have the opportunity to select a new runbook to add, as well as new team members to bring into the incident.

Private Runbooks

When running a private incident, it’s highly likely that you and your team will need to run a different kind of process than you would for a public incident. To that end, we added the ability to mark a runbook as private.

Only “Owner” users or “Members” with the private permission enabled are able to create and edit these private runbooks. This restriction ensures that no one can update your private runbooks to, say, inadvertently send private information out to a status page or via an email runbooks step.

Just like a public runbook, you can set private runbooks to automatically attach to new private incidents (they won’t attach when converting an incident to private but will be available for users to manually attach during conversion). And private runbooks are not available when manually attaching runbooks to a public incident so you won’t trigger any high-risk processes when running public incidents.

We’re excited to hear how you and your team are running private incidents. To get started today, create a new private runbook and open a test private incident. You can also read more in our docs here.

Today, we're launching a new way to coordinate response efforts in complex incidents: related incidents. Related incidents allow you to connect many incidents underneath a single parent incident, making it easy to connect multiple incidents that have been opened for the same root cause or even break down large incidents into smaller component parts.

Related Incidents make it easy to share status updates between related incidents. And closing our related incidents is easy too: when you resolve a parent incident, you can choose between resolving or archiving the children.

Whether your team is looking to consolidate multiple incidents or coordinate work into specific work streams, try out Related Incidents today by visiting an Incident page and editing Related Incidents in the sidebar. You can also run /fh related in Slack. You can also learn more about Related Incidents by reading our blog post or visiting our docs.

Our team has been busy packing all kinds of goodies into our UI Refresh. Read on and make sure that you checkout the UI Refresh Beta announcement to get yourself enrolled.

Tasks and Follow-Ups Views

• Have you ever had an incident-related task or follow-up that you just couldn’t find? Or a list of things your team needs to follow-up on from a recent incident? With the new Task and Follow-up views in the UI Refresh beta, you can easily find tasks and follow-ups that belong to you or anyone else on the team. Filter by state, ticket priority, and more. If you’re already enrolled in the UI beta, navigate to the Incidents page to Tasks and Follow-Ups in the sidebar.

Unarchiving Incidents

• When someone on your team prematurely archives an incident, it can be frustrating to try to get that incident re-opened. Starting today, you can easily find archived incidents in the new Incidents page by filtering “Archived” from the quick filter list. Each archived incident has an unarchive button in the action menu. Clicking this button will bring the incident back into whatever state it was in when it was archived (active, resolved, etc.).

Introducing the Notification Center

• For users enrolled in our UI Refresh beta, we’re happy to offer a new way to stay in the know about incidents happening in your workspace. The notification center will display notifications for your incidents: both the incidents your responding to as well as the ones that you’re watching. You’ll get notifications for status updates, roles assignments and other big changes for your incidents.

Import User Avatars from Slack

• We’re now allowing users to import a user avatar from their Slack account as part of the UI Refresh beta. Adding your avatar not only makes your presence in the FireHydrant app more personalized, but it also makes it easier for other users to understand when you’ve been involved in resolving an incident or participating in a retrospective. You can import your Slack avatar by editing your profile after opting in to the new UI beta.

Bugs and Fixes

• We added a new Date Time hover state to show both UTC and local user time.
• We updated the command center to allow for file uploading (drag-and-drop or click to upload).
• We fixed an issue with YAML formatting for Backstage YAML imports.
• We fixed missing status tags on Follow-ups on Incident pages.

If you're using Slack Enterprise Grid, you can now install the FireHydrant Slack app across multiple workspaces. Enterprise Grid support lets you enable incident management for all of their workspaces, making it easy to manage incidents in Slack for all of their teams.

Users across Enterprise Grid workspaces can now run a single incident management process with easy Slack commands, firing off incidents in the location where your responding team expects them. For instance, a team in a Security workspace might see an issue, run /fh new and an incident will be opened up in the Engineering workspaces #incidents channel.

To learn more about Enterprise Grid and how you can set it up for your team, checkout our docs.

Command Bar

• If you've used any modern developer tools, you'll be familiar with the "Command + K" utilities bars that have become ever present. We've added a command bar for searching, navigating, and taking action on your incidents, making it even easier to use our web application when you're responding to incidents. If you've enrolled in our new UI Refresh beta, you'll see the command bar the next time you log in. You can use the "command+k" hotkey combination or just click on the search bar in the header.

Auto-complete for Liquid Variables

• We know that trying to remember all the possible properties of liquid templating variables can be challenging. So we added support for auto-completing liquid variables when using them in Runbook steps. For instance, if you want to add the incident name to a custom Slack message, you can add your standard curly braces and start typing incident. You'll be presented with available variables as well as the properties of that variable once you select it. Additionally, you can check for any available filters by typing the pipe symbol: |. Try it out now by opening a runbook and editing any step with a text field.

Adding External Links

• When responding to incidents, there are all kinds of external resources that are helpful to accelerating the response process: dashboards, documents, links to your UI, etc. Now, you can easily add those links to your incident in FireHydrant in the sidebar of an incident page in FireHydrant. For each link, you can add a name and the url for the link. Whenever a link is added, we'll thread a Slack message to your pinned message and send it to the channel.

Jira Data Center 9 Support

• We updated our Jira Data Center integration to support the latest major version. Since the APIs differ between version 8 and version 9, we have flagged the newest version until all customers have migrated to the latest version. Please reach out to your customer success team if you are using Jira Data Center 9.

Bugs and Fixes

• We fixed an issue with Jira ticket creation from runbook steps
• We fixed a bug with pagination on the task lists page
• We fixed a bug with Zoom bridges
• We fixed an issue with large CSV downloads
• We added the ability to filter by event type on the incidents API endpoint
• We added the ability to invite groups to an incident channel

Today, we're launching 5 new integrations to make it easier to automatically declare incidents. You can use the power of Alert Routing with your monitors and alerts from your favorite monitoring tools: Datadog, Honeycomb, Prometheus' Alertmanager, New Relic, and BugSnug. Alert Routing will allow you to use data from these monitoring tools to build precise rules for automatically opening incidents, routing actionable messages to your teams Slack channels, logging a message, or just ignoring the low level alerts.

These new integrations provide a simple webhook interface with a new guided onboarding experience to help you properly configure the webhook and any payloads that might need to be customized in your monitoring tool.

Check out the new new integrations by logging into your account and navigating to the Integrations page and clicking on the monitoring tool that you'd like to try. And as always, you can check out our docs to learn more about how to get started:

• Datadog
• Honeycomb
• New Relic
• Alertmanager
• BugSnag

A Personalized Dashboard When you log in to FireHydrant, now, you'll find a list of active incidents that involve you or your team. Additionally, you can quickly browse all of the active incidents in your organization. You'll also find any tasks from active incidents as well as any follow-ups assigned to you in FireHydrant or your ticketing system.

A Simpler Navigation Not only did we move our navigation to the top of the screen, but we've also simplified how to access the most important content: your incidents and incident management process tools like Runbooks and Catalog. Any configuration or setup flows have been moved to Settings to keep a single, simple admin area.

Simplified Tables We've updated our tables across the application to not only offer a simpler search and filtering experience, but also show you the most relevant information for your incidents, services, users, and more.

These changes should help make the experience of responding to incidents in FireHydrant not only easier but importantly, faster.

To get started, navigate to User > My Account and scroll to the bottom of the page to find the new "Beta Features" section. Select "UI Redesign", click "Update", and refresh the page.

Today, we're launching Resolved Incidents to help you and your team track historical or even quickly-resolved incidents. Sometimes, an incident ends up being a quick-win, a Slack thread, or for some reason, just not a part of your typical incident management process. These incidents don't require the same automation and process that active incidents do, and so for all of those incidents, you can now create Resolved Incidents in FireHydrant. Tracking these incidents, even without the full incident management process can help your teams learn more through retrospectives and even richer data about your incidents.

When creating a Resolved Incident, you will add a start and end time to your incident which will be used to populate the started and resolved milestones. These incidents, as the name implies, begin at the "Resolved" milestone. The forms for Resolved incidents will respect your settings for required fields and any additional fields that you and your team want to add for the incident (including any Runbooks that you may wish to run explicitly).

Importantly, Resolved Incidents will skip any automatic runbook triggers, so you don't need to worry about firing off pagers or unnecessary status page updates.

Check out Resolved Incidents today by logging into FireHydrant and selecting "Create Resolved Incident" from the new menu item next to the "Declare Incident" button. You can also run our new Slack command: /fh create-resolved to create a Resolved Incident in Slack. And as always, you can check out our docs to learn more about creating a Resolved Incident.

Team Assignment in Declare Incident Form

• Users can now assign a team to an incident when declaring one in the web UI. This allows users, regardless of where they are declaring an incident, to bring the right team into the incident.

SCIM support for Google Workspaces

• For organizations using Google Workspace, we now offer full SCIM support for provisioning and de-provisioning users.

Updated Incident Export to async with email follow-up

• To improve the performance and user experience of exporting incidents from the Incidents list view in FireHydrant, we are now running the export task asynchronously and emailing users when it's ready to download.

Convert Tasks to Follow Up Tickets

• We re-added the ability to change any of your in-incident tasks to follow-up tickets. This makes it easy to ensure important work makes it from the incident into follow-ups.

Bugs and Fixes

• We updated tabs in Command Center and Retrospective views to be responsive
• We now hide incident types in the incident declaration form if not incident types are present
• Fixed bug with data export dropping incidents
• We added support For Liquid Templating in "Add a Bookmark" Runbook Step
• We updated our GoLang API client
• We now allow requiring passwords on our Zoom meeting integration
• We added more useful upstream error reporting from Jira
• We fixed an issue with Slack usernames showing up in Google Meet links
• We fixed an issue with incident labels not filtering properly on the Incident list page
• We fixed an issue with system-wide status page not updating
• We fixed an issue with directly inviting @usernames to a Slack channel via runbooks
• We fixed a bug where discarded users were being auto-linked in Slack
• We fixed a bug where starring Slack messages wasn't properly adding a star to timeline items in FireHydrant

Assign Teams when declaring an incident in Slack and via the API

• When your team is declaring an incident in Slack or via the API, they can easily assign a team to the incident using any team you’ve created in FireHydrant. Team assignment is now available as a controllable field and may need to be added to your modal in Organization > Settings > Incident fields settings. If you're declaring an incident via the API, you can now pass an array of ids through the parameter team_ids.

Retrieve on-call schedules associated with Functionalities

• We added the ability to retrieve an on-call schedule from your 3rd party tool when you’ve linked that schedule to a Functionality in FireHydrant. Previously, this was limited to just Services.

Bugs and Fixes

• We fixed an issue with our New Incident status would sometimes double post in Slack
• We fixed an issue with timestamps not saving for custom change events
• We fixed an issue with syncing inactive PagerDuty users

New Runbook Step to Invite Users to Channel

• We added a new runbook step to allow you to invite specific users, via Slack handles or email address, to an incident channel. This allows you to add your own Slackbots as well as specific team members who should participate in all incidents.

Beta: Owners can remove timeline events

• We added the ability to remove Slack and FireHydrant chat messages from the incidnet timeline in FireHydrant to help with controlling sensitive information like personally identifying information, API keys, and other common security concerns. This functionality is limited to the owner role in FireHydrant. To enroll in the beta, reach out to your customer success manager.

Advanced fields management for the Multistep modal

• For teams using the multistep modal for creating new incidents in Slack, you can now manage the fields that are presented in that modal. To edit which fields are visible, navigate to the Organization Settings page and update the "Incident fields settings" for the Advanced modal.

Rollback: New Update Modal Experience

• Last week we rolled out a multistep update modal to Slack and have rolled that back to a private beta for teams that are using our multi-step incident creation modal as well. If you'd like to enrolled in the beta, reach out to your customer success manager.

Bugs and Fixes

• We added contextual icons for runbook steps in the incident timeline
• We fixed a bug with login retries
• We fixed a bug with change events UI incorrectly wrapping text

Today, we're launching a fresh, new way to declare incidents in FireHydrant through our web app. You and your team can now quickly and efficiently kick off new incidents in FireHydrant, getting just the right amount of data for the incident when kicking it off.

This new form allows you to use incident types to add context, tags, services, and more to make sure that your most common types of incidents can be quickly declared.

Additionally, this new form has been slimmed down for the user, moving any non-required fields into an optional section at the bottom of the form, allowing your team members to add in the fields that they are confident about and ignoring the ones that they aren't sure about.

Check out the new Declare Incident form today by logging into FireHydrant and clicking the "Declare Incident" button in the top right corner (don't worry, you can look at the form without actually opening an incident). And as always, you can check out our docs to learn more about kicking off an incident.

Today we're launching Alert Routes, a powerful new way for you to manage the alerts you're sending to FireHydrant. For you highest priority alerts, you can automatically open incidents, passing along key details from the alert. For alerts that are specific to a team or a service, you can send those alerts to the appropriate channel. Additionally, you can create a log message for the alert or ignore it altogether.

Alert Routes, like Runbooks, creates powerful automation based on conditional logic. You can create conditions from any of the data that's included in your alert: priority, summary, related infrastructure and more!

Starting today, Alert Routes is available for all existing alerting integrations in FireHydrant including PagerDuty, OpsGenie, and Splunk On-Call (VictorOps).

To learn more about Alert Routes, checkout our blog post or read the docs. Better yet, head over to your alerting provider integration to start automating your alerts today.

Automatic Slack Account Linking

• We updated the Slack linking functionality to automatically link accounts between FireHydrant and Slack when the emails match. We added an additional “alternate email” field on the user account settings to make sure any alternate Slack account emails are considered as well.

New Teams Page

• We updated our teams list and view page to be more consistent with the rest of the web app. Easily view active and past incidents that the team was assigned to, explore their responsibilities within the service catalog, and more.

Multi-Channel Guests

• We now support multi-channel guests linking Slack accounts to FireHydrant, allowing guests to fully participate in your incident management process, running Slack commands, having assigned roles, and more.

New /fh update modal experience

• We shipped a new modal for the update command in Slack. This new modal enables you to update all the details about an incident in addition to the current functionality of posting a message to the status page.

Bugs and Updates

• We fixed an issue where PagerDuty alerts were showing discarded services
• We updated our mechanism for inviting users to a channel to retry each user individually to avoid batch errors.

FireHydrant is hard at work this year improving the experience of our entire platform. And this includes all the places that you might interact with our product, even our API docs and help our general documentation.

Over the last few months, we’ve been quietly hacking away at an improved documentation site, and today, we’re announcing the release of our new docs site: https://firehydrant.com/docs.

While the content of the docs is exactly the same (we're working on improving that as well!), we've made a ton of changes to make the site easier for you

• Dark mode for late-night perusers 🌙🌕
• Whole-site fuzzy search
• Table of contents per-article
• Syntax highlighting for code snippets

We hope you enjoy the updated docs experience, and if you have any feedback or questions, please let us know by reaching out to your Customer Success Manager know or connecting with us via the support portal!

Check out the new docs today! https://firehydrant.com/docs.

Timeline Messages from Slack Connect Users

• We added support for ingesting messages from Slack Connect users into the incident timeline, ensuring that even more context is captured during an incident.

Secrets Management and JSON Headers for Webhooks in Runbooks

• We added the ability to add and manage secrets to be used when authenticating and securing webhooks in the Send a Webhook runbook step. These secrets can be added to the JSON Headers field using a liquid template to pull them in {{ secrets.your_secret_name}}

Update Channel Names in Runbooks

• We updated our Create Channel runbook step to allow you to rename the channel based on new conditions or changes to the incident. You can now add this step multiple times in an incident and subsequent runs of this step will update the channel name.

Priority Field from OpsGenie in Runbooks

• We added the priority field from OpsGenie alerts into the Create OpsGenie Incident runbook step

Login Redirects URLs

• We updated our login flow to capture a redirect url, ensuring logged out users return to the page they’re expecting to after logging in

API Documentation Updates

• We fixed several type-based issues in our documentation

Bugs and Fixes

• We fixed a bug with timeline chronology when updating incident details
• We fixed an issue with editing timeline events during retros
• We fixed a UI sizing issue with conditions labels

Today we're releasing a new way to collaborate in retrospectives using comments on all editable fields as well as timeline events. Users can add, edit, and remove comments and can even react to others' comments with a Github-style set of Emojis. Commenting is the core part of collaboration on the web today, and we're excited to start making our retrospectives more interactive and powerful for teams running full-cycle incident management.

To learn more about using comments in your retrospectives, check out our blog post or read the docs. Better yet, you can start a game day incident and run a retrospective to try out commenting for yourself!

Team Assigment in Runbooks

• We added the ability for team assignment to be used as a condition in runbook conditional statements.

Bugs and Fixes

• We fixed an issue with spacing in the incident timeline
• We fixed an issue with alerts in OpsGenie and VictorOps not properly attaching to incidents
• We added pagination to Service Catalog search when creating Runbook steps
• We fixed an issue with some PagerDuty alerts not auto-resolving
• We shortened the Message Import Slack message in the FireHydrant Slack app
• We updated API docs for many of our endpoints

Add incident impact

• We added a new runbook step called Add Incident Impact to allow you to easily add service catalog components to an incident with condition status.

Fixes and Bugs

• We added the ability to unarchive an incident via the API
• We added the ability to automatically link incidents created in third party alerting providers to your existing incident when using the /fh page commands
• We added drag and drop image uploading to the command center
• We removed truncated incident titles on the Incident list view and are now showing full titles even for multi-line titles
• We added team assignments to the incident API allowing you to easily see which teams have been assigned to the incident
• We added the ability to set Priority level when paging to OpsGenie for either Runbooks or Slack
• We fixed a bug so that Severity Matrix no longer displays Discarded Services
• We fixed a bug for posting incidents to Statuspage.io with “ minor outage” impact
• We fixed an issue where status page update wouldn’t post with invalid Liquid syntax: now we will show raw title instead of failing the update

Zoom Oauth Application

• Today, we're launching a new OAuth-based integration with Zoom to make it easier to integrate your Zoom account.
• On June 1st, Zoom will deprecate their JWT application support, and we will deprecate the prior version of our Zoom integration at that time.
• To learn more, read our documentation on the new Zoom OAuth integration.

fh.new

• We've added a new shortcut to open incidents for your team. Using our new link at https://fh.new, users can quickly open a new incident in the FireHydrant UI.

Fixes and Bugs

• We added the ability to add new timeline events during a retrospective
• We updated incident types to allow for the creation of private incidents
• We added the ability to edit status page updates in the command center, allowing you to change any message you've already posted to your status page.
• We added the ability to skip required fields when testing a runbook
• We updated retrospective fields to editable components to avoid overwriting and to allow for in-context preview of Markdown
• We added the ability to change the severity or priority of an incident in the retrospective
• We improved validation warnings when filling out required fields in retrospectives
• We fixed an issue with Jira server ticket status syncing
• We updated runbook Slack channel creation to always create private channels when run inside a private incident

New Functionality for the Update Incident Details Runbook Step

We've added two additional functionalities to our update incident details runbook step.

• The first new feature is the ability to add labels to an incident.
• The second new feature is the ability to post automatic status page updates as part of a larger state change or as a standalone update. By default, notes will be included on the internal incident status page, and can be selected for other status pages.

Read more about this step in our documentation.

Bugs and Fixes

• We fixed a bug where incident creation time was missing from the retrospective view.
• We improved teams filtering in the incident list.
• We improved real time functionality on the new command center: incident links and runbook step executions now update in real time.
• We improved filtering on incident timeline to properly show all milestone updates as we would previously exclude them if they were associated to a status page update.

Slack message migration

• Today, we're releasing a Slack message shortcut that allows you to import any message or thread into an existing FireHydrant incident. This will help ensure that FireHydrant has a complete conversation record about a given incident and notify users that their messages have been imported into an incident channel so they can join the action easily. Any message can be imported by clicking More message shortcuts... in Slack and then searching for Add message to incident.

Bugs and Fixes

• Enforcing creating a single retrospective for incidents: We've updated creating retrospectives to ensure that only one would ever be created. Specific scenarios would lead to multiple retrospectives, and with no way to switch between them in the UI, we were inconsistently showing data.
• Enable sending retrospectives to teams: We've added functionality to sharing retrospectives to send a report to an entire team at publishing time. This should reduce the number of selections made at publish time.
• Double-creating services: We fixed a bug that led to creating services twice when manually creating them in the web UI.
• Deleting attached alerts: We fixed a bug that was not allowing linked alerts to be removed from an incident.
• Hiding options to open incidents in Slack automatically: If you have required fields for declaring incidents, opening incidents directly from our Slack alert prompt could lead to a situation where the incident was opened without those required fields. If you are in that specific situation, we'll now hide the button to open the incident automatically and will prompt you to open it using the declaration form.
• Add a warning message when an incident type is missing a required field: When selecting an incident type that is missing a given required field, we'll show you which field is missing and prompt you to complete it before declaring your incident.

Modern engineering teams have spoken: not only do they want to streamline and learn from incidents, they want to actually use them to improve reliability. Moreover, as economic winds change, teams want to understand the impact of their investment in incident management. To close that loop, they need a path to understanding incidents across time, infrastructure, milestones, and teams. Those insights are now generally available for FireHydrant Enterprise customers. Our upgraded Analytics dashboard makes it easier to understand at a glance how incidents affect your systems and your people, allowing you to drive toward true reliability improvements.

In addition to the updated dashboard, we’ve also made it easier to export visualized and raw data to share your incident management performance with leaders and other teams. Combined, these features allow teams to understand and share data about incident management programs in a way that was previously impossible in any tool without cumbersome data analysis and business intelligence work. For the first time, teams can instantly visualize incident impact by service, functionality, and teams without stitching together data from disparate sources, piping it into a BI tool, and manually building out queries and charts.

Check out more at our blog post or our knowledge base articles for more information.

Follow up priorities

• This new field on follow up tickets will help your team prioritize items coming out of your incident and retrospective to understand what needs to be worked on now and what can wait until later. Priorities can be customized to fit your teams specific naming conventions and we are enabling the priority field with five default values. Priorities can be renamed and reordered to fit your teams needs. All followups will be shown in sorted priority order on your incidents and retrospectives and priority can be field mapped to any third party ticketing provider. Please talk to your CSM to have priorities enabled for your organization.

Support for EU PagerDuty instances

• We've added support for custom domains in our PagerDuty configuration so if you are using an EU instance of PagerDuty, FireHydrant will be able to fully support you.

Bugs and Fixes

• Ticketing Settings: To go along with our release of priorities on follow ups, we have consolidated priority configuration, template values, and default projects to their own configuration page called Ticketing Settings.
• Resolution time filtering in API: We've updated filtering parameters in our API to include searching for incidents by resolution time. This is available by including resolved_at_or_after in your parameters
• Logout bug fix: We fixed a bug that was leading to an error page when users logged out.

Automated Status Page Updates

• Using the runbook step "Update Incident Details", users can now add automated udpates to their status pages on regular cadences, further reducing the toil associated with resolving incidents. Try it out now by editing or adding an Update Incident Details runbook step and adding status pages to the Status Pages field.

Organization-Wide Ticket Templates

• For all users in your organization, you can now add ticket templates for any follow-ups that are added to an incident. Importantly, templates can include liquid templating so important information about the incident can be automatically added to all of your follow-up tickets. Try it out now by editing your organization setting

Bugs and Fixes

• Alignment Fixes: We shipped some changes to the layouts of several of our most common pages.
• Alias Add Tags: We shipped a change to the /fh add tags commands that drops users into the tag editing portion of the update incident form, uniying their experience across all updates.

50k Incident benchmark We analyzed 50,000 resolved incidents and identified the top trends to help you level up your incident management process. Check out just some of the behaviors we found that have a positive impact on MTTR and much more in the full report: https://firehydrant.com/reports/incident-benchmarks/

Bugs and Fixes

• Feature Enhancement: we added the ability to send an email when publishing a retrospective. The email includes a PDF summary and can be sent to any stakeholders by entering their email address at time of publising.
• Page Alignment: we fixed some inconsistencies across page layouts
• Improved ebounce on Retros: we improved the form performance for users who are working on completing a retrospective
• Lessons Learned Bug Fix: we fixed bug that caused values to be overwritten in specific lessons learned
• Tags/Labels Bug Fix: we improved the display of incident tags and labels in the retrospective
• Page Service Bug Fix: we fixed a bug so that the system correctly invokes page service command when it’s kicked off from a runbook step
• Performance Improvements: we improved memory and network usage on the frontend for faster experiences
• Design System Updates: we started rolling out a new color palette across the app
• Jira Field Mapping Improvement: we improved Jira field mapping to include Epics as a destination for incident tickets
• Quality of Life Improvement: we disabled SEO indexing on long lived internal status pages

Template variables in Jira field mapping

• FireHydrant has added liquid templating support for literal Jira custom field mappings.
• This enables incident data to be populated to Jira tickets
• Check out our support documentation for more

Post incident updates in thread

• When an incident updates occur, now all incident messages across Slack can receive threaded updates

Bugs and Fixes

• Fixed a bug where values were improperly populating in specific retrospective fields
• Fixed a bug where retrospective pdfs formatted data incorrectly
• Added suggested change events to new command center
• Updated the import messages Slack command to post messages in a thread instead of to the channel
• Linked alerts no longer count as notes for runbook conditions
• All active status pages are now selected by default when posting updates in Slack
• Fixed a bug where certain users were unable to subscribe to status pages
• We no longer allow runbook conditions to include a trailing and/or operator without an additional condition
• Fixed a bug where Slack messages were not updating with created third party links after an action item is created
• Improved search algorithm for tags on incidents
• Improved change events and incident archival in the web command center
• Fixes an issue with data export to provide longer lived urls
• Allow for autorecording webex meetings

Okta Integration Network Listing

• FireHydrant is now an Okta Verified SAML and SCIM integration.
• Visit https://www.okta.com/integrations/firehydrant/ to add the integration to your Okta application for out of the box user provisioning and single sign on.

Bugs and Fixes

• Fixed a SCIM issue for users reprovisioning with changing email addresses
• Performance improvements for ingesting alerts from integration partners
• Fixed an issue where Operational was the default condition when declaring incidents
• Adding alerts to incidents no longer triggers note specific runbook conditions
• Fix label and tag grouping in the new command center
• Fixed issue with Zoom integration where join before host was incorrectly being set
• Fixed issue with Webex integration where join before host was incorrectly being set
• Improve performance on the retrospectives page
• Fix a bug where certain characters were breaking search results

A whole new retrospective experience

• Today, we're bringing our newly designed retrospective experience out of private beta and into public beta. Taking cues from our redesigned incident command center over the summer, we've made individual retrospective tasks easier to complete, timeline curation significantly simpler, and added a whole new way to add action items during the course of your retrospective.

Incident Participation Statistics

• Not only did we redesign retrospectives, we're bringing some new functionality as well. When loading up retrospectives in FireHydrant, you'll now be able to see data for the users that participated in that incident broken out by time in incident, starred messages, and actions taken. Empower your retro facilitators to easily find the people responsible for mitigation. As a bonus, this data set is available as template variables for use in any runbook step.

Saved Incident Views

• A few weeks ago we launched saved views on services. Today, we're opening that up to incidents as well. Now you can save organization wide views for your list of incidents, allowing teams to quickly get back to commonly used filters. As a bonus, you can also set default views so your filtered list is automatically set whenever you visit https://app.firehydrant.io/incidents

Updated Labels and Tags in New Command Center

• For teams using tags and labels for incidents, you’ll now find a simpler way to interact with them in the new command center view. During an incident, you can add any tags or labels that your team will use for breaking down and understanding incidents in the future. Check out the new labels and tags by navigating to any incident page.

Auto Add Responding Teams for Incidents

• Last week, we launched the ability to add responding teams directly to Slack channels. We’ve now made this team assingment more powerful by allowing you to automatically pull in team members into an incident based on their on-call schedule when an incident includes their service. Check out our guide on managing services and functionalities with teams.

Auto Add Responding Teams to Slack Channels

• When a team has been marked as a Responding Team for a service in FireHydrant, all members of that team can now be automatically added to Slack channels for incidents that connected to that service. To try it out, add a responding team to a service in your service catalog and check the “Auto-add Responding Team” toggle.

Refreshed Teams Management Views

• We updated the interfaces for managing teams in FireHydrant to reduce clutter and make it easier to understand what services and functionalities are owned by a specific team. You can check out the updated designs by visiting the Teams page as well as viewing any of your teams’ specific pages.

Add follow ups during an Incident

• You can now create follow ups during an incident in the new Command Center interface. Before, you would have to wait until the retrospective had been started to add follow-up items in Jira or Shortcut. Now, you can those follow-up items as the incident is progressing.

Bugs and Fixes

• Updated SCIM documentation for API users with correct content-type and added a safe role check and spec to avoid SCIM failing when handling discarded users.
• Fix for Change Events firing even after Github integration is uninstalled
• Added exception/logging into Opsgenie API client for better debugging
• Fixed an issue with the Create Zoom runbook step

Default Views in Service Catalog

• Building off of the Saved Views work, we brought in a quick win to allow users to save a Default View based on a Saved View. When set, this view will now load on the first visit to the Service Catalog Overview. We also placed helpful UX Tooltips to help educate this new functionality. Last, a new pill tag to show when you are on the default view. Default View is set at a user level and not for the organization.

Ability to automatically add tags to an incident by default

• Clients can now automate the addition of incident tags via the incident_update runbook step. Not only can the user pick from an existing list of tags, but they can also create a new tag on the spot.

Error Reporting for POST /v1/incidents

• Instead of seeing a 500 error for posting with an invalid service ID, we will now return a 400 with the description of the failure.

Example response body :

{ ...

    "messages": [

        "impacts service id 123456-ad43-adff-8b5e-64257 could not be found",

        "impacts condition_id 64257-ad43-adff-8b5e-123456 could not be found"

    ]

}

Bugs and other Fixes

• Fixed an issue with Link & Import and integration links for Functionalities
• Updated API Docs for /service
• Fixed bug where Integration form was resetting because of Entitlements check and page focus
• Fixed the bad search query of Backstage Services matching FireHydrant Services.
• Turned on edit support for integration links on externally managed Services.
• Fixed an issue with service pagination.
• Updated the Edit Service form delete & save to new design language
• Updated how we run team assignment for slack commands to an aysnc job
• Fixed an issue where the input to any of the fields on that page are disappearing when you navigate away

Filtering UI Updates

• Users can now instantly see their filters updated when filtering services in the main service catalog view. Selecting a team, tier, or connected functionality now immediately updates the list view. Keep an eye out for this pattern rolling out across the application!

Test runbook without other default runbooks attaching

• Previously, customers had no way to test a runbook in isolation; hitting the "Test" button from a runbook would declare a new incident and specify that runbook for attachment, but any other runbooks that attach automatically would also start running for that incident. We introduced the ability to test a single runbook and only that single runbook.

Add participation statistics to template variables

• We took our participation statistics to the next level by adding incident stats to the IncidentEntity in our liquid templates. This exposes it to both the public API and for liquid rendering in Runbook steps.

  *Incident Stats*
  {% assign stats = incident.participation_stats %}
  Total Messages: {{ stats.chat_messages }}
  Starred Messages: {{ stats.starred_messages }}
  Tasks Completed: {{ stats.tasks_completed }}
  Actions Taken: {{ stats.actions_taken }}
  
  {% for user in incident.participation_stats.user_stats %}
    *{{ user.user.name }}*:
    * {{user.chat_messages}} messages
    * {{user.starred_messages}} starred messages
    * {{user.tasks_completed}} tasks completed
    * {{user.actions_taken}} actions taken
    * {{user.time_in_incident}} in incident
  {% endfor %}
  

These new template variables make it easy to share stats in Slack messages, emails, and even via webhooks for custom integrations.

🐛 Bug Fixes

• Fixed an issue with incorrect system data on Status Pages
• Fixed issue with users receiving emails after they are removed from org

Add common fields as top level liquid variable throughout runbooks

• Users now have access to ticket, number, severity, and priority, and some other fields at the top level. Prior to this change those fields were nested and required users to dig through the incident's data in Runbooks. This means instead of typing {{ incident.incident_tickets.first.attachments.first.display_text }} the field is available as {{ incident.ticket }} for example.

Local time display to launch 22 Sep 2022

• Many of you have expressed a preference for displaying times in your local timezone to prevent having to mentally convert to UTC. In response, on Thursday 22 September at 7:30am Pacific Time, FireHydrant will be changing the default timezone display to match a user’s machine time. This will not impact how datetime stamps are stored, which will remain in UTC. Enterprise customer organizations who prefer to remain on UTC should reach out to their CSMs to opt out.

Saved Views for Service Catalog

• Users now have the ability to save views based on filter conditions for their Service Catalog Overview. This allows for users to efficiently view and get to the services they care about most with one click. We have also introduced multi-select filtering capabilities and the ability to filter based on Functionalities and Responding Teams.

Auto-Add Responding Team to Incident Channel - Beta As part of this beta, any time a Service or Functionality is added to an incident, we will automatically add the Responding Team Members to the slack Incident Channel if members have slack enabled. To be added to the beta program, reach out to your CSM for access.

Improved Service & Functionalities Import Flow

• We built a more seamless experience to showcase all integrations that allow imports, explicit prerequisites on how to get started, and better selection capabilities. Now when you setup an integration and start the import process, you have the ability to quickly import all third party services as new FireHydrant services in one click. Additionally, this will automatically link FireHydrant services to those third party services on import. To get started visit the Services page, click ,Add Service, and select Import from third party.

Ability to mention users in Runbook steps

• Now, you can manually @ users or use the field slack_user_id as liquid code while configuring a Runbook step. For example, using Hi, @slack_handle in a Runstep that posts to a custom message to a Slack channel would behave similar to if a user had directly posted to Slack. Another example would be to run Hi, <@{{incident.role_assignments.first.user.slack_user_id}}> to auto populate the handle with the user of the first role assignment.

Timeline View Enhancements

• All users will notice a redesigned incident view. Now it’s easier to see the relevant information from timelines: milestones are more visible while less relevant information is less prominent.

Add context to Task update messages in Slack

• This patch seeks to provide clarity as to what actually changes with a task when it's updated. Our previous message did not let you know what actually changed, and it was be difficult to find that out. This will add additional context to the task update message.

Ability to support liquid formatting in Team Channel field

• Previously the liquid templating in the comma separated Team Channel field of the notify channel step was not supported. Adding this functionality addresses a need for dynamically messaging a channel based on different values in the payload. We were already allowing the use of liquid templates for the message field in the "Notify channel with a custom message" runbook step, but not in the "Comma separated channels" field.

Opening incident from alert with modifications now links alert to incident

• When you click Yes, open, the incident automatically kicks off with the alert attached. But if you select Yes, open & edit, the incident did not open with that ticket attached, and actually creates a new PagerDuty incident. We are now linking a PagerDuty alert when creating a new incident from the alert with modifications.

Fix an issue preventing certain milestone update messages in Slack

• Normally, when an incident is resolved and that incident has a Slack channel, we'll post our "milestone update" message as a threaded reply to that Slack channel's pinned status message (e.g. "This incident has transitioned from Mitigated to Resolved"). We got a bug report about this behavior not working wWhen a link alert resolved an incident the incident is resolved via a linked alert. For example, if an incident on FireHydrant was opened via or linked to an alert on PagerDuty, resolving that PagerDuty alert will subsequently resolve the incident on FireHydrant, but with no message being posted to the incident's Slack Channel.

/fh page service post an ephemeral message

• Previously, running /fh page service posted a message that anybody in the channel could see and interact with. This can be incredibly annoying for the person trying to run the command if somebody else comes in and ends up selecting something without realizing that they are stepping on OP's toes. The message is now ephemeral. Selecting a pageable service results in it being paged as normal, with the notification message also being ephemeral.

Linked Zendesk tickets now capture impacted customer org

• Zendesk tickets linked to an incident now display the impacted customer org from Zendesk. This enhancement is only available in the new incident Command Center view. Learn more about our Zendesk integration here.

Status Page Performance Tuning

• Users of our status pages will notice a decrease in load times. For example, one organization saw their status page load time go from 192s to 7s. The performance enhancement is rolled out to all users.

Add ability to field map additional Jira fields with custom types

• Added support for insight based custom fields in the Jira integration. Updated issues with datetime parsing and assignee fields.

Bug Fixes

• Enforce clicking preview always places you in preview mode. Prior to this change, it was easy to get lost in multi-step changes. For example, clicking cancel while editing the preview might place a user back in edit mode if they clicked preview again. Now, when users hit the preview button, it takes them to the expected preview.
• Direct message a user to next if certain message shortcuts fail due to being run in private channels. The FireHydrant Slack app will now directly message a user when message shortcuts fail due to restricted privileges from private channels or direct messages. This change guides the user to actionable next steps or informs them of the permission restriction rather than failing silently.

Slack message shortcuts We have added two new message shortcuts in Slack to make it easier to declare incidents and import external messages to your incident channel. Message shortcuts are available in Slack by clicking the overflow menu when hovering over a message.

Clicking on the message shortcut for ‘Open a new incident’ will prepopulate the incident name with the contents of the message and if the message is over 255 characters it will include the entire message as the description of the incident. This should make it even faster to declare incidents with preset values in key fields.

Clicking on the message shortcut for ‘Add message to incident’ will allow you to migrate a message or thread from any channel in your Slack workspace to a FireHydrant incident. We’ll post the imported messages into the incident timeline and notify the original channel and thread about messages moving to an ongoing incident to ensure that responders are working in the incident.

New Service Catalog Onboarding We improved the Service Catalog home space with a new onboarding video and highlighted important support docs first time users may want to read. Now when you onboard new users to your organization in FireHydrant, they can quickly understand the importance of your Service catalog setup.

Easier Label setup for Services and Functionalities We added the same enhancement found on the Service Catalog overview to service and functionality editing. When adding a label to a service or functionality you can now see all the pre-existing labels used in your catalog.

Status Page Update Optimizations We’ve improved a significant amount of performance bottlenecks in Status Pages, resulting in a 93% latency reduction for new incidents and updates made to pages. Keep an eye out for more improvements coming soon!

Service Dependencies now have an enhanced graph visualization so you can easily explore across your catalog.

New Graph View - Explore and discover specific service nodes to see if an incident impacts them. You can zoom in and out and highlight impacted infrastructure for more extensive catalogs to traverse your services.

Service Snapshot - Double-click on any service node to open a side panel about that service. You'll see a preview of that Service's Analytics, Owning/Responding Teams, and Active Incidents.

Add to Incident - When exploring dependencies, you can add them to current incidents through our new "Add service to incident" button. Bring in the service experts to quickly resolve issues across your infrastructure.

Get started with Service Dependencies by visiting your Service Catalog and using the new Actions column to see your graph and add dependencies. Check out our blog to learn more about our service dependencies philosophy.

We now comply with SCIM 2.0 protocol allowing compatibility with any identity provider supporting SCIM. These supported providers include: Okta, Azure AD, Ping, and OneLogin.

Actions supported

• Add/Deactivate users: All users can easily be added/deactivated to FireHydrant.
• Update users: Changing user access or roles in your identity provider automatically persists into FireHydrant.
• Create/Deactivate Groups: User groups can be pushed from your provider and assigned to match teams in FireHydrant.

To get started setting up SCIM with FireHydrant, take a look at our support documentation here.

Easier filtering with Labels

• We made filtering across your Service catalog that much easier by pre-listing all labels currently active in your label dropdown. This removes the guesswork to promote better standardization across services and functionalities.

Analytics Tab for Functionalities

• Inside the refreshed functionalities view is now the option to see incident analytics. To see this data, start by going to your functionalities section within your catalog and select a specific functionality. In this functionality is the new Analytics Tab so you can quickly drill down on a functionalities performance.

Required fields have been a hot topic at FireHydrant. Choose too many (or the wrong ones), and you unnecessarily annoy your team during an incident or encourage sloppy data entry that someone has to come back and clean up manually. Don't use them at all and risk insufficient data to efficiently propel an incident toward resolution. But despite the controversy, required fields for incident declaration was one of our most-requested features — and it's now available as an option for configuring your instance.

The debate within our product team centered around ensuring that we didn't build any impediments to people's first experience with the product, declaring incidents. We feel that 1) it should be as easy and intuitive as possible for anyone to declare an incident, and 2) teams must be able to capture the full scope of their incident from the moment something seems off. We considered whether required fields would force investigation outside of FireHydrant incidents. Or worse, push people to abandon the incident declaration process altogether.

But there's a bigger picture: driving progressive reliability practices inside organizations. And that means working toward capturing necessary and accurate data from the moment an incident is declared. Ultimately, we believe that requiring a field or two upon incident declaration can play an essential role in improving an organization's overall maturity in incident management. If you're considering required fields as part of your process, we've got a few tips for ensuring that you can capture consistent incident data while promoting confidence and efficiency among responders.

See more about how we're using required fields internally at FireHydrant by checking out our recent blog https://firehydrant.com/blog/how-to-use-required-fields-for-incident-delcaration/ and our documentation https://support.firehydrant.com/hc/en-us/articles/8499733491348-Required-Fields-for-incident-Declaration

We significantly improved usability of FireHydrant’s Terraform Provider by adding sample code and logging, and fixing bugs for the following:

Resources

• firehydrant_environment
• firehydrant_functionality
• firehydrant_runbook
• firehydrant_severity
• firehydrant_team

Data sources

• firehydrant_environment
• firehydrant_functionality
• firehydrant_runbook
• firehydrant_runbook_action
• firehydrant_service
• firehydrant_services

Note that several breaking changes were made, including the planned deprecation of the services attribute in the resource firehydrant_functionality. There are also a number of breaking changes for the resource firehydrant_runbook. The steps attribute is now required, the steps config attribute is now a JSON string, and the type and severities attribute have been removed. In order to upgrade to 0.3.0, you will need to destroy your existing runbooks and recreate them after changing your configuration.

Additionally, the following new provider resources and data sources were added:

Resources

• firehydrant_incident_role
• firehydrant_priority
• firehydrant_service_dependency
• firehydrant_task_list

Data sources

• firehydrant_incident_role
• firehydrant_priority
• firehydrant_severity
• firehydrant_task_list

For more details see the FireHydrant Terraform Provider repo changelog.

Onboarding Updates

• We’ve all experienced the frustration of opening a new app or one we haven’t used recently, and not knowing where to start. To help improve onboarding for new and infrequent FireHydrant users, we’ve added an overview video, module descriptions, and links to knowledgebase articles.

Display the last update to specific status pages

• We will now display the last posted update to a status page incident on the Status Page tab in our updated command center. This should allow your incident communicator to quickly assess when the last update went out and what the contents of that update were. Keep your eyes open for more communication related improvements over the coming weeks.

Role assignment details in Slack

• We now include specific roles that people are assigned in the status message for an incident. Get up to speed with who is doing what right when joining an incident channel.

New Contextual Menu for Functionalities and Services

• Users can now select from a list of actions for any functionality in their functionalities table to make a change. No need to open a detail page individually to edit it or navigate to an incident and edit it to include a functionality.

Functionalities endpoint performance improvements

• Our functionalities endpoint has been slimmed down with the lite param and the removal of N+1 queries. This makes the endpoint usable by companies with more robust data loads. For example, one large organization's requests were reduced in time from >40s to just 1.4s!

Link directly to the service attribute you want to change

• When clicking on a link to change an aspect of a service, you are directed to that point in the service form. Previously, a user would land at the top of a long form, then search for the input they wanted to change.

Redirect sends users to the top of a page

• Previously, after completing a form and loading the next page, users arrived at the new page, scrolled down somewhere near the bottom. Really odd and confusing.

Tooltips on Services and Functionalities index tables

• Make life a little easier by adding a brief explanation of some of our column headings. Unobtrusive, but there if you need it.

Helper text in services and functionality forms

• Similar to our table tooltips, we’re offering some support while filling out the forms with some descriptive help text for tier, owner and responding teams inputs.

Bugs and Fixes

• Bug: Starred events in the new command center will update in real time as they are starred in Slack, no page refresh required.
• API Addition: The ticketing endpoint will now return timestamp data.

• Command Center has a refreshed look.
  • A new, cleaner interface for managing incidents is available today for all users and can be accessed in the Command Center UI by enabling "New Command Center" in the banner at the top of the page.
  • More easily navigate the timeline of events in your incident while easily accessing all of the metadata associated with the incident.
  • Services, Functionalities, and Environments now link to their pages in the command center to quickly navigate to their homepages.
• Functionalities Overview got a refresh as well.
  • With the latest features added to Functionalities, we cleaned up the overview to better showcase their new owning teams, impact status, and when they were last updated. These new display fields can be filtered on via the overview page. In addition, you can set labels and filter on them across your functionalities.
  • On a Functionality’s details page, you can click any label assigned. This will redirect you to the overview page and filter on that key:value pair to display all functionalities using these same values.
• Prepopulate new accounts with default incident types
  • When new accounts are created in FireHydrant, they will now come with incident types defined by our customer base. We’ve started with the seven most common incident types we’ve seen here at FireHydrant to ensure you can get up and running with FireHydrant as quickly as possible.
• Updated suggestion messages in Slack
  • When a service is attached to an incident, we will now display associated teams and functionalities to that service directly in Slack to quickly get the right people and data associated with your incident. We’ve also applied the same treatment to functionalities. Based on the work to update functionalities with associated teams, we can now show team and service relationships to functionalities inline in Slack when they are added to your incident.
• Fixes and Enhancements
  • 🔥 🚀 🌟 Emojis 😱are now supported in the incident timeline from Slack events.
  • Bugfix The Slack channel incorrectly displayed incident tickets.
  • Bugfix When a user navigates away from the timeline tab and comes back, sometimes it fails to fetch.

Updates to the Service Catalog

• Improved Functionalities view inside Service Catalog: Our Functionalities feature inside Service Catalog has a whole new look with lots of new features. The Functionalities overview, as well as detail pages, have new incident information views to quickly see what is impacted. This release also unlocks the ability for functionalities to do the following: Assign Owning & Responding Teams, Link third party Services, Auto-Alerting, new Related Service Tab, Labels, External Links, and other meta-data.
• Managing Service Editing Permissions by Owning Team: You can now limit access to editing or deleting services to specific teams and their members. This is so you can have confidence in your service catalog definitions remaining protected. To activate this permission feature, assign an Owning Team to a Service. To learn more see our Editing Permissions documentation.

Updates to the Slack App

• New slack command: /fh page functionality: Linking a functionality to a third party integration service will allow you to page this functionality via slack. Head into slack and type in /fh page functionality. This will populate a dropdown list of all functionalities with integration links configured. Select the functionality you would like to page. FireHydrant’s slack bot will fire off a page to the escalation policy linked to this functionality.
• Updated the Slack message for assigning a task list: We updated the incident channel and DM messages for adding a task-list to an incident and assigning it to a responder.
• Updated the /fh add task-list command modal: This change adds to improving and unifying our task list experience. We have rebuilt the tasks list modal and added command summaries to other parts of our task list experience, we wanted to do the same here.
• Updated the Role Assignment DM to use BlockKit: This release replaces the message that a user receives when being assigned to a role in an incident to match our new design styling.
• Updated the team suggestion message in the incident channel: If you add an impacted service to an incident, and that service has a responding (not just owning) team, we send a suggestion message about assigning said team to the incident.

Introducing our new Zendesk integration To more easily capture customer impact FireHydrant Enterprise tier users can now integrate with Zendesk Support. Our initial release allows Zendesk ticket linking to FireHydrant incidents. To get started see our Zendesk integration documentation. Stay tuned for enhancements coming next quarter, including capturing impacted customers and automating status updates back to support tickets.

Jira integration admin improvements

• We’ve made several changes to clarify the difference between global Jira integration authorization and account linking. Account linking is used to associate individual users to their corresponding Jira account for Jira ticket creator attribution. Under User > My Account, the Linked Account section now uses the verbiage Link.
• Global Jira integration reauthorization is required to reauthorize the Jira integration connection when Atlassian tokens are rotated. Only the person/account who set up the Jira integration can reauthorize the global integration. This person/account is now displayed on the Jira integration settings. If that person is logged in, they can now also reauthorize the global integration connection from that screen.
• Lastly, we’ve added a new Jira troubleshooting document that details self-service actions users can take to diagnose and correct common Jira fault scenarios.

Starting today, FireHydrant has a wholly redesigned Task experience for incident response.

• You can now predefine Task Lists before an incident to be attached via Runbook automation or manually throughout the incident. We’ve been using Task Lists internally for deprecating playbooks on cluster failovers, compliance tasks, incident commander responsibilities, and Slack reviews. Task lists ensure that your process is as seamless to use as possible.
• Task creation has been rebuilt from the ground up in Slack. All our commands have a fresh coat of paint to make it straightforward to create new tasks, add task lists to incidents, and assign those tasks during the incident. Messages for Tasks are more compact, and we’ve made the assignment DMs easier to take action on for assignees.
• The most significant update has focused on Task management in Slack. Now running /fh tasks will open a project management modal for all of your incident tasks. You can filter based on assignment, state, and task list while quickly being able to update the assignee and Task state without leaving that screen.

Starting today, incident response in both Slack and the Web has been completely redesigned and simplified. Let’s talk through some of the updates.

Guided workflows to help responders ramp

• Simplified incident declaration - speed up declaration, reduce fear in new responders, and stay flexible for power users with our new multi-step incident declaration.
• Updated status message - Get new responders and interested parties up to speed quickly with an updated /fh status command that is also sent as an ephemeral message to all new channel joiners.
• Contextual buttons - The status and new incident messages are now milestone aware to help responders take actions quickly based on the state of the incident.
• Updated Milestones - First Action is gone, replaced with a much easier to understand Investigating milestone. Additionally, we’ve added IDentified between Investigating and Mitigated.
• Slack Link reminders - Whenever unlinked users join an incident channel, FIreHydrant will send them a reminder to link their accounts
• Not and empty conditions for runbooks - Ensure process adherence by running runbook steps when roles, impact, and other incident metadata is missing.
• Incident Update Runbook step - Enforce incident state with Automatic escalations, milestone changes, and description updates are now all possible through runbooks to allow for even more flexibility for our power users.
• Notify channel step actions - Ensure consistent process, Incident messages now can prompt users to take actions through buttons, making it easier for custom process during the course of an incident.
• Slack Bookmarks - Reduce Noise with Bookmarks. Bookmarks allow for custom links and FH created information to be added to an incident channel, reducing noise in the channel.

Slack commands are more powerful and straightforward

• Start retro command - /fh start retro - Users can start the retro preparation immediately after resolving and can start the retro with proper information while the incident is still fresh.
• Updated Resolve incident command - /fh resolve - Post resolution updates to status pages and ensure that accidental resolutions happen less
• Updated assign team command - /fh assign team - Understand who you’re bringing into an incident when assigning a team
• Contextual Help menu - /fh help - Improving the design of this menu should make it easier for new responders to be less overwhelmed by the breadth of functionality in FireHydrant.

Simplified design to eliminate noise

• Reduced message noisiness - Shortening FH messages allows the most important information, the chat between responders to be more prominently displayed
• Threaded updates - By including updates to an incident in a single place, Slack users can scroll back on incident updates without having to scroll through the whole incident channel.

A redesigned Command Center adds Incident Response redundancy

• Command Center V2 - A completely redesigned incident command center in the web to allow users to respond to incidents in both the FireHydrant application and in Slack. Protect against Slack outages with chatops functionality and give your responders the ability to work wherever they are comfortable.

See more at our blog post at firehydrant.com/blog/redesigned-and-redundant-incident-response/

Incident Data CSV Export To address complex reporting and data science use cases, bulk incident data CSV export is now available to Enterprise users. After enabling the integration, bulk incident data will be exported daily to CSV file format and accessible via the FireHydrant API. For more details on configuration and data format see the user documentation.

Labels inside services now a clickable asset for search We decided to boost the power of labels inside services so users can easily search for shared key:value pairs across their catalog. Once a user adds a label to a service, they can now click on that label and be taken to their catalog overview with it automatically filtered. The overview will display all services that share these labels with a pre-injected query into the filter view.

This past week the team took some time to run a bug bash. Here's a high level overview of what we fixed, we closed almost 100 bugs over the past week.

Runbook fixes - Notify steps with buttons now can be properly removed, closed milestone state is no longer displayed, search works correctly on current milestone dropdown

Incident command fixes - Fixed issue with unassigned user roles displaying time incorrectly, incident creation time no longer changes when the started milestone changes, fixed an issue with incident CSVs not returning all incidents, internal status pages visits now return a proper authorization error, fixed help menu in slack, fixed broken links in the command center, service condition labels are now present in the pdf, CSS fixes on the status page as reported by StackOverflow.

Improved Service API

As the usage for Service Catalog has increased so has the need to take time to improve the scalability for retrieving service information across our product. The Service Catalog Team, with lead from Patick Vilhena, has improved the latency for returning service information for large catalogs with hundreds of services.

Feature - Added New Runbook Audit Logs endpoint for paid plan users. Enterprise customers can reach out- to their Customer Success Manager to enable this feature. Feature - Added API endpoint to create chat event types Feature - Bulk update events posted to the incident status message as a reply

Feature - Paid plan users can now automate Webex bridge creation through a new Webex integration Feature - Improved API for faster lookup of services from your service catalog Feature - Managing Runbook Editing Permissions on Owning Team - Users can now add Owning Teams to Runbooks to prevent edits from members outside their teams. Users with an Owner role will still have global editing permissions to avoid lockout Feature - Operational Readiness Templates available to quickly create service standards

Feature - Slack Improvments

1. Contextual buttons added to the Slack message to easily kick off a FireHydrant incident
2. Severity Description - When you choose a severity inside of Slack, we will update the help text under the field to include the severity description.
3. Fallback text for notifications - no more “this content cannot be displayed”
4. ‘/fh assign team’ - Assign Team Command opens detailed modal
5. ‘/fh start retro` command - Running this command will open a modal that will allow for an update of the incident metadata while kicking off a retrospective.

Feature - Team Assignment Updates

1. Filter incidents by assigned team using the API
2. Metrics on a team basis - We can now allow for filtering analytics data based on a team being assigned to an incident

Bug Fixed - Updating an incident’s impact will no longer post empty messages to Slack when there were no changes

Notice Retrospective Layout Updated to display incident description and customer impact prominently at the top of the retro

Retrospective Changes The design of retrospectives didn't lead users to fill out their data as they completed a retrospective correctly. The retrospective PDF displays the incident description and customer impact at the top left of the page and is usually the first thing that someone will read when looking at it. However, to edit those fields in a retro, you had to click an overflow menu to get to the form fields. We've changed the layout to ensure that these two fields display prominently at the top of the retro.

Operational Readiness Templates When it comes to defining a Readiness Checklist, organizations are looking for recommendations on how to get started on building their first checklist.

FireHydrant has built two template checklists for users to get started: Production Readiness Checklist & Security Compliance Checklist. Each list is a starting point for organizations to apply service standards during creation.

Feature - Users can now automate retrospective data export to Google Docs. Feature - FireHydrant now supports the creation of the most common Jira Cloud and Server epic ticket types and linking of FireHydrant incident data to Jira custom fields. Learn more here.

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. This means that during incidents, responders spend valuable time determining the full impact that could be spent remediating core issues. With the addition of service dependencies to FireHydrant Service Catalog, responders can immediately identify the full scope of service and customer impact across an incident with a comprehensive view of downstream and upstream dependencies. And since Service Catalog documents service ownership, they can quickly pull in the needed responding teams.

Learn more at our blog post here

Feature - Users can define task lists for incidents, assign them to an incident as part of a runbook step, and add them to an active incident in slack Feature - Updated /fh help experience in an incident channel to include guidance for tasks and task lists Feature - Runbook Ownership now available to lock down Runbook editing to Owning Teams

Notice - Tasks will not be assigned tickets even if there is a default ticketing integration in the organization

Feature - FireHydrant is now available in MS Teams Feature - New Service Details Overview for Service Catalog Feature - Terraform 0.2.0 released Feature - Now a verified Terraform Provider Feature - New Free Tier experience for small teams released Feature - Free Tier Update: Can now set up a single project for Jira cloud Feature - We now support integration with multiple Shortcut projects Feature - We released new guidance for automating Jira multi-project configuration via the API. Feature - Added improved error handling for errors associated with Jira multi-project configuration.

Bug - Better messaging for Runbook Step access for Free Tier users Bug - Fixed a bug with the Jira multi-project configuration settings to allow new tickets to have a default status of "In Progress" Bug - Fixed a bug where FireHydrant status updates for linked action items were not propagating to linked Jira tickets Bug - Reordered the multi-project configuration UI to be more logical in field mapping flow. Incident ticket field mappings are now grouped, as are action item ticket field mappings Bug - Fixed a bug related to Zoom user assignment for schedule maintenance runbooks Bug - Fixed pagination to better support users with long lists of Jira projects

Feature - New Operational Readiness Checklist feature for Service Catalog. Learn more here. Feature - Users can now export incident data into Confluence for collaborative activities, like incident reports and retrospectives. Get started by configuring your Confluence integration. Feature - We now support integration with multiple Jira Cloud and Jira On-Prem projects. This allows users to create incident tickets and action items in team-specific Jira projects directly from FireHydrant. This release also introduces a new integration-specific create incident ticket Runbook step. We ask all customers using the Jira integration to transition to their Runbooks to the new step, as we plan to deprecate the generic step at the end of June. Feature - Two new template variables are now supported, incident.last_note.body and incident.last_note.created_at to capture the most recent incident update and timestamp regardless of whether the update was generated by a single action or by bulk update. We plan to deprecate incident.last_update at the end of June 2022 and request that customers migrate over to the newer incident.last_note.body. Feature - Added Mean Time to Mitigation (MTTM) to our weekly summary email

Bug - Fixed alert ingestion for when an integration link is established between PagerDuty and a FireHydrant Service. Bug - Fixed runbook rules to prevent customers from creating a runbook rule that would not work with time constraints beyond the maximum time allowed for rule execution. Bug - Fixed bug that was preventing some customers from exporting incident and service data into a CSV Bug - Fixed bug to maintain consistent formatting of incident duration in our Overview and Analytics pages Bug - Fixed bug that was causing some customers to view updates on their internal incident status page after the incident was resolved Bug - Help icon in runbook conditions routes to the correct help documentation Bug - Fixed bug that was causing issues in weekly summary emails.

Feature - New Account Overview to show feature usage within your account. Feature - Task management is now available in Slack Feature - Incident tags are now sorted alphabetically in Slack

Bug - Fixed bug that was preventing some users from being able to save changes to a statuspage Bug - Fixed bug that caused some runbook steps to fail. Bug - Fixed bug that kept some users from being able to edit change events in a retro

Feature - Users now more easily edit updates to status pages in the FH UI. Feature - Terraform Provider v0.1.4 released Feature - Enabled extra validation to prevent duplicate service names on creation Feature - Added additional access controls for private incidents Feature - Improved design for /fh help in Slack incident channels Feature - New Integration Links section has been added to Services to easily link and update alerting integrations to services. To test this out: 1. Select a service from the Service Overview page 2. Click 'Edit details' 3. Scroll down to the section titled 'Integration links'

Bug - Fixed ‘/fh page service’ command so that hyperlinks go to direct service and not overall Service Catalog. Bug - When configuring runbook steps, the help icon now directs users to the correct documentation. Bug - Fixed [runbook condition, "time since last incident note added"](https://support.firehydrant.io/hc/en-us/articles/360061144571-Communicating-with-teams-using-Runbook-steps "runbook condition, "time since last incident note added"") so that it only fires with the Slack command /fh add note, and not with /fh add update. Bug - Fixed liquid formatting template variable issue with the Email Notification Runbook Step Bug - Fixed Slack bug for VictorOps alerts that caused alerts to not go to their intended channel Bug - Fixed bug that prevented incident milestone times from updating Bug - Fixed Slack /fh link command bug that prevented role assignment Bug - Fixed bug that prevented auto-assigning of a linked user in Slack Bug - Fixed UI padding and spacing issues on Retrospective Configuration page in FH web. Bug - In the FireHydrant UI, addressed inconsistent experience that occurred when trying to assign a Team on the Overview page and none of the team members were assigned default roles. There are also clearer error messages calling out potential issues in this area. Bug - Fixed bug that allowed users to create runbooks with the same name Bug - Fixed incorrect error that occurred when using filter "retrospective completed" on the Incidents page in FH web Bug - Fixed bug that caused an incident status page to be blank Bug - Fixed bugs in weekly summary email related to labeling and filtering of email recipients

Feature - You can now create private incidents (beta) in FireHydrant. This is a great solution for security and compliance teams who need to collaborate with their engineering counterparts to resolve incidents. Learn more here. Feature - Added the ability to edit service catalog when using the /fh update command. Feature - Runbooks now display the user name and time of when it was last modified. Feature - Service catalog details can now be edited from the slack command /fh update. Feature - Roles can now be assigned after an incident is resolved, either from Slack or the UI. This is especially useful if you want to assign incident retrospective roles. Feature - New Incident Runbook View. Now you can easily access all executed Runbooks and dive deeper on each step. Feature - Services now include the power of incident analytics. Service owners can now get a quick overview of the reliability of their services over the past month Bug - Use of "Internal Status Page" is now consistent in both Slack and the UI. Before this fix, Slack showed "Private Status Page". Bug - Action items will always keep assignee info- even after they are marked 'done'. Bug - The naming of all teams is now unique. Duplicate teams names will be validated and prevented when trying to save.

Feature - New Runbook step: Auto-add Services Related To Functionality. Feature - When linking services to VictorOps and GitHub, their respective routing keys appear with the external link name. Feature - For clarity, new incident Slack modals contain a Description field instead of a Summary field. The description field does not have a character limit. Feature - Private Slack Channels are available and can be added by using Runbook steps Bug - Added the option to turn off paging of the default VictorOps escalation policy if there are no impacted services in an incident. Bug - When selecting Jira projects in slack, we improved the dropdown to show your default project as well as other projects you can select and not show blank. Bug - Enforced limiting the ability to add changes to the 'new note' and 'edit incident' actions; changes can only be added to only active incidents in the Slack UI. (This prevents users from adding details or notes to inactive incidents.) Bug - Fixed bug that was creating duplicate incidents in Slack.

Feature - Our new Service catalog feature has been released! Feel free to check out our new product release and to learn how to manage your services with your incident response. Check out this resource to get started Feature - VictorOps integration capabilities have been updated. If you use VictorOps, you can now more easily create and manage incidents from Runbook steps and VictorOps alerts Feature - ServiceNow integration is available for users to create incidents in ServiceNow from FireHydrant Runbook steps Bug - Fixed bug causing duplicate weekly summary emails from being sent to users Bug - Form error information is now displayed for PagerDuty and Opsgenie during setup instead of a 500 error (when API token is missing) Bug - Fixed bug that prevented users from removing a channel from the Channel for alerts Slack configuration

Bug - Saved searches now appear in the dropdown on page load; multiple saved searches can be updated and/or deleted without navigating away and back Bug - The /fh action items command now includes action items that do not contain a description Bug - The Slack setup page now redirects correctly in the README page Bug - Slack commands work regardless of use of upper or lower case

Feature - The new Incident Header provides better usability on the overview page of an Incident. The header now shows “Elapsed Time” under the incident title, as well an Edit button that opens a modal where you can view and edit important incident details. Additionally, you can update incident milestones and severity with a simple dropdown. You can also edit milestone times from within the header. This streamlines the incident response process by giving you access to multiple important functions from one central location.

Bug - Fixed a bug that was causing Zoom bridges to duplicate. When you declare an incident that has multiple Runbooks attached (and a step to create a Zoom bridge is included in more than one Runbook), only one Zoom bridge will be established for the incident. Bug - Fixed an issue that prevented action items that exceeded Slack’s character limit from displaying correctly in Slack. Now action items will be truncated in Slack, and users can view the full action item in the FireHydrant UI. Bug - The "New Incident" and "Edit Incident" Slack modals now list environments, functionalities, and services (as they appear in dropdown menus) in alphabetical order.

Feature - New metric card shows important Retrospective data like percentage of retros completed, min time to retro, max time to retro, and mean retro gap Bug - Fixed a bug that was causing google meet links to fail Bug - Fixed a bug that was causing a NameError in production for Runbooks

Bug - Fixed an issue that prevented publication of an incident event when a new Slack message with an attachment is created Bug - Fixed an issue that was preventing Google Meet integration from completeing successfully Bug - Fixed an issue that prevented the 'Cancel' and 'Save' buttons on the Retrospective Configuration page from scrolling with the rest of the controls on the page Bug - Fixed an issue that prevented the value in the "label value" field to include whitespace characters

Feature - Added the ability to properly assign service ownership from the "Teams" page Feature - Added the ability to search/filter for projects in the FireHydrant UI Feature - Added the option to configure multiple connections for the same integration Feature - New ConnectionStatuses API endpoint provides connection statuses about integrations Feature - Link to Notification settings page is available under the User menu

Bug - Fixed an issue with table borders in Safari Bug - Fixed Analytics view to exclude user involvements for archived incidents Bug - Changed imports page to a paginated list of importable objects, improving page performance Bug - "Customer impacted" details are now displayed on the incidents page

Feature - New Integration, Checkly Feature - New Integration, Google Meet Feature - Display active incidents on individual service page Feature - New Slack scope available for pinning initial incident message Feature - Display initial incident message to user joining Slack channel for the first time Feature - Add Tiers to services and runbook conditions

Bug - Alphabetize lists in dropdowns across app Bug - Improve service command search results Bug - Display all available PagerDuty services and Escalation Policies in dropdowns

Feature - Allow for internal status pages to be turned off Feature - Update Integrations page to make installing new integrations easier Feature - Added ability to associate reporter of FireHydrant action item to Jira Cloud reporter Feature - Allow associating owning team to a service Feature - Updated API documentation at developers.firehydrant.io Feature - Add incident tags to analytics filtering Feature - Display better user meta information on teams page

Bug - Properly handle new lines in markdown fields Bug - Allow Jira OnPrem credentials to be modified Bug - Fixed a bug where selecting custom date ranges in analytics would occasionally break Bug - Allow users to enter Zoom room first if they were not the incident opener

Feature - Customizable Slack Incident Modal - The new customizable Slack incident modal enables users to easily configure which fields they would like to appear in their modal, if they have requirements that differ from the default settings. Feature - Incident Tags - Incident Tags empower users to store more metadata on incidents, making it easier to query and get actionable insights compared to traditional labels. Now, with Incident Tags, users can tag incidents, filter by tags, and even automate Runbooks based on tag conditions.
Feature - Slack Service Command - The service command allows you to quickly query the metadata of a service from within Slack. Run /fh service to see it in action.

Feature - Added ability to reopen incidents from the web UI Feature - Added buttons to run commands from Slack help menu

Bug - Fix validation issue with Zoom runbook steps

Feature - Allow for star reactions in Slack to work when the incident is already resolved Feature - Invite all users to a channel in Slack if they already are assigned a role Feature - Add a new field on an incident for Customer Impact Feature - Update graphs on the overview page and improve analytics algorithms Feature - Add ability to configure what emoji causes a message to be starred in the FireHydrant timeline Feature - Add a response emoji when FireHydrant has successfully starred a timeline event in Slack (defaults to :fire: but can be changed) Feature - Added assigned roles to incident messages posted by FireHydrant

Bug - Fixed a bug where labels had incorrect validation requirements Bug - Fixed a bug where not all starred events populated on the PDF timeline Bug - Fixed a bug where selecting custom date ranges in analytics would occasionally break Bug - Fixed a bug where action item updates in Slack were in title case Bug - Fixed a bug where incident resolution times were incorrectly displayed on the incident table

Feature - We updated the onboarding experience for new accounts Feature - Using incident updates will now always post to the internal status page for an incident whether on Slack or the UI Feature - Added the ability to search in all runbook step configuration dropdowns Feature - You can now export incident data based on the current filter view as a CSV Feature - We added a new runbook step to assign a role in your incident. This can be assigned from a FireHydrant user, a user from an Opegenie or PagerDuty schedule, or the person who opened the incident

Bug - Fixed a bug where the analytics filter didn't stay in the header on scrolling Bug - Fixed a bug where infrastructure was not available to search in the condition UI Bug - Fixed a bug where starred events were not populating fully on page load Bug - Fixed a bug where incidents were still showing on status pages after they were archived Bug - Fixed a bug where password complexity requirements were not shown on the accept invitation page Bug - Fixed a bug where services were not correctly attaching to an incident if they were included on a linked Opsgenie alert

Change - Moved the bot users page to the Organization tab in the navigation

Runbook templates: An easier way to automate your processes Starting out with runbooks can be daunting, we've built a way to implement our best practices into a runbook that can be implemented in a single click. On top of this, there's now even more ways to attach runbooks to your incidents and a much easier way to test out the runbook that you're currently working on. Check it all out here.

Dig in deeper with filtering in analytics While our analytics platform provided some initial ways to examine your incident data, we always wanted a way to surface even more relevant data from your historical incidents. Now you can! With analytic filtering, you can take the same conditional evaluation from runbooks and filter your analytics based on that. Check out some initial ideas and learn more here.

Use additional variables in Runbooks for more customization We're always looking to make Runbooks more valuable. This month, we have made additional variables available in runbooks.

incident.last_update gives you the last note that was posted to the incident

incident.report_id gives you the id of the retrospective that is created so you can link to our generated pdf from any runbook step that takes template variables

New Integrations: Opsgenie & VictorOps

Now available - we've just released a first class Opsgenie integration. Now FireHydrant can automatically associate incidents to alerts, assign team members to on-call schedules, open incidents in Slack in a single click from new alerts, and more. Customers who've leveraged our alerting integrations have seen their mean time to respond drop by 75%! Learn more about what this integration can do here.

Not only do we support Opsgenie, we also support VictorOps as well! Now enjoy the ability to manage your response in FireHydrant no matter which alerting provider you use. Learn more on how to configure VictorOps here.

Templatize your incident types

Templatize your incident types Do you consistently have similar types of incidents? Do you wish that the correct infrastructure was always attached to the incidents that you consistently spin up? Using incident types you can now template all of the details, including runbooks, to include on an incident with only one selection. Learn more about how to implement types and get your team to open incidents faster and more reliably.

Use /fh and /incident

Let's face it, typing out /firehydrant in Slack every time you want to run a command takes too long. We have introduced two new commands that behave in the exact same way as /firehydrant but shorter! Now you can use /fh or /incident in Slack to interact with the bot.

ICYMI: Try conditions in FireHydrant Runbooks

FireHydrant Runbooks have consistently been the most powerful and popular way of implementing your automated incident response process. However, after receiving a lot of great feedback, we extended the ability to create automation beyond the start of your incident. With conditions, you can now add automation to any point of your incident response lifecycle.

You can find our announcement post here, but try out these 2 easy ways for you to get started: how to build automated stakeholder email notifications and how to archive your Slack channel after an incident has ended.

Get reporting how you want it: CSV export of analytics data

FireHydrant captures some of the most full featured incident metrics, but we know that these metrics are extremely valuable in other places outside of the FireHydrant platform. Now you can quickly export your quarterly SEV1 incident data as CSV to populate charts for your next board meeting or capacity planning. Visit Analytics to export some data.

A few little things to take note

We’re always making small, but mighty, improvements to the platform to increase how easy things are to use. This month we added support for searching for incidents based off of their number on the incidents list, dynamic title tags for easier history browsing, updates to the responders algorithm to more correctly show who interacted on an incident, and displaying who opened an incident on the incidents list. Go to the platform to check them out!

1. A new and improved analytics experience

After a lot of time in the lab, we’re excited to announce a new analytics experience. We now offer incident data covering Severities, Responders, and Infrastructure. Each category will return data around total time impacted, number of incidents, and mean time statistics. Click here to see your new analytics experience.

2. The Damage Report you’ve always wanted

Getting caught up on a long-running incident can be frustrating. Try out the new Slack command /firehydrant status to get an incident overview without scrolling back or bothering your team and link to common actions in a message only visible to you.

3. FireHydrant’s new Slack App Home

If you’ve ever wondered what the current state of incidents are across your org or wanted a quick rundown of multiple fires you’re fighting simultaneously, we’ve released the perfect feature for you. With our new Slack App home you can easily see the current state of incidents. Check it out by going to the Apps section in Slack.

4. Now easily archive incident channels

You’ve asked, we’ve answered. We’ve built a runbook step so you can automate archiving your incident channel after the completion of your retrospective. To enable the functionality all you need to do is add an ‘Archive Incident Channel’ step into your runbook and we handle the rest, automatically archiving your incident channel after you complete your retrospective.

ICYMI: We’ve got a Zoom Integration

Creating a conference bridge for an incident is one of the most common requests we have heard. Our new Zoom integration will automatically spin up a bridge and make it even easier for your response team to get on the same page.

Quickly Know Who’s On Call

Knowing who is on call is already difficult and now, when you're remote, knowing who is on call can present a whole other set of challenges. To help you keep track, we’ve built a new Slack command to easily see on-calls and escalation policies for any given service in your organization, inside of the tool that you are using most frequently: Slack. Try it out by running /firehydrant on-call.

Webhook Runbook Step

Integrating your incident response with your other applications has now become significantly easier. You can now leverage the automation of Runbooks to send webhooks based on the state of your incident.

New Slack Commands

Remembering all of FireHydrant's Slack commands can be challenging in the heat of an incident. By running /firehydrant you can now see a list of available commands and run them with one click.

Fire hydrants usually have a firehose hooked up, and boy do we have a firehose of updates for you. We've been focused on making FireHydrant simpler to use and more deeply integrated with existing workflows to make managing your complex systems easier. Let's dive in!

Status pages

Status pages are a common tool used in incident communication, by closely coupling our incident response platform to our status pages we have made keeping stakeholders and customers updated on your remediation easier than ever. By running your incident response through FireHydrant the manual work of keeping communications up to date are automated letting you focus on remediation. Read more about the updates Status Page Announcement.

Incident Page Redesign

We have simplified and redesigned the incident page to make it easier than ever to discover information and interact with your incident through our Incident Command Center. Read more about the updates Incident Page Redesign.

PagerDuty Integration Updates

In an effort to make it even faster to spin up an incident in FireHydrant we have upgraded our Alerting integrations to go from detected alert to opened incident in a single click on Slack. Read more about it PagerDuty Integration Updates.

Ticketing - Clubhouse

We're excited to announce that we are adding support for Clubhouse to our ticketing system. Now you can create an incident ticket that all action items from your incident and retrospective are easily tracked and assigned to. With the Clubhouse integration, tickets created in FireHydrant are created and synced to tickets in Clubhouse. Read more about Ticketing here.

Additional Incident types

As companies continue to expand the scope of what constitutes an incident FireHydrant is following suit. You can now designate incidents in FireHydrant as Unplanned Downtime, Scheduled Maintenance, or Gameday. By running these three types of incidents on FireHydrant you can leverage the automation of runbooks to ensure that your process adheres to your plans every single time.

Today we're releasing a vastly improved system for how you track work that stems from incidents. With our new ticketing functionality you are able to create actionable items for incidents as tasks or follow ups.

With this improvement, we're also excited to announce our Jira integration (For both Cloud and Server) have been updated to support the new ticket workflows.

FireHydrant now includes release notes within the application itself. We know that not all users of FireHydrant are subscribed to our mailing list, so this allows your team members to keep up-to-date about changes to our product. We’ll continue to publish product announcements on our blog and to the mailing list as well.

Anyone in Slack can open incidents now

Sometimes there isn't an alert. Instead you have the town locals knocking on your door with pitchforks. The best detection you have sometimes is your own team, because of that, now anyone can run /firehydrant new in Slack to kick off an incident.

Let us handle the severity for you

Who has time to pick the severity when opening an incident? We're also happy to go into the matrix, severity matrix that is. Customize your severity levels and pick the conditions that set them when an incident is opened. Less time deciphering a severity, more time putting out a fire.

Jira

We're also announcing our Beta Jira integration today as well! Whenever you create incidents and action items in FireHydrant, we'll send them to Jira as well so you can track it in everyone's favorite cloud hosted todo list.

Announcing Webhooks

If you want to build tools to communicate updates for deployments, it can be a ride on the struggle bus if you don't have a single source of truth.

Using FireHydrant's change log solves the problem of "source of truth", but until today there was no way to receive a notification about a change being deployed.

With our new webhooks feature, we've solved just that. Receive a HTTP request anytime a change event is created or updated to one or multiple endpoints that you get to configure!

Get hooked up

Keep your frequent searches for later

Using our change events filtering, you can find deploys to production for a certain service in the last hour with ease. Today we're also happy to announce that you can save these searches for later with our new Saved Search functionality. This is available or all users today on the change events page.

Today we're happy to announce our single sign on support and updates to our postmortem functionality.

Single Sign On Is Available

If you are using an SSO provider, you might be happy to hear we now support logging in with it! We have so many post-it notes with our passwords scattered around our office we had a fire hazard (forced pun intended).

It's easy to get started with it (we promise), just head to our Wiki to learn how!

Generate Postmortem PDFs

Along with moving postmortems into a single view (who likes multiple steps?), we're also happy to announce postmortems can now generate a PDF of your report! Not only that, users that participated in the report will also receive a shiny new email informing them about the published report too.