Hey there, Firefighters 🧑‍🚒 We've got some major updates for you this week!

🚨 Round Robin for Signals Escalation Policies

Balance your team's workload and reduce alert fatigue with our new Round Robin feature for Signals Escalation Policies. This feature is designed to make alert escalations smarter, fairer, and more team-friendly by allowing you to automate the sequential assignment of new alerts.

Choose between:

Distribute Evenly: Moves to the next target for each new alert and when the policy repeats – great for keeping things fair and balanced.

Distribute Consistently: With this option, alerts will always start with the first target but move on to the next target when the policy repeats.

We’ve also added the ability to add “additional targets” to your escalation policies — think Slack channels, external team members, webhooks, or even other escalation policies.

Read the blog to learn more.

🔄 ServiceNow Integration (Beta)

Our newest enterprise integration brings FireHydrant and ServiceNow together, creating a seamless bridge between engineering and the rest of your organization. Now your teams can work in their preferred platform while staying perfectly in sync.

• Create incidents bi-directionally between platforms
• Map custom and standard table fields for perfect data alignment
• Sync your CMDB with FireHydrant's Service Catalog
• Share Work Notes automatically across both platforms
• Convert Follow-Up tasks into ServiceNow problem tickets
• Keep critical incident details synchronized in real-time

Read the blog to learn more.

💬 Run Incidents From Microsoft Teams Group Chats

You can now auto-create Microsoft Teams group chats and seamlessly run your incidents within them – fully interacting with FireHydrant, just as you would from channels. Opposed to team channels that may limit who is involved in incidents, group chats allow anyone across the company to be involved in the discussion, making cross-functional collaboration easier than ever.

Read the blog to learn more.

📝 Reimagined Retrospectives (Beta)

We've completely rebuilt our Retrospectives experience to make post-incident learning more powerful, customizable, and collaborative than ever.

This new version brings:

• Custom templates – great for different teams, Incident types, or services
• Real-time collaborative editing
• A rich text editor that allows you to format and customize your answers
• Automated template attachment via a new Runbook step
• Ability to add multiple Retrospectives to Incidents
• AI-powered answer generation
• Polished export of your retros to Google Docs, Confluence, and PDF

Read the blog to learn more.

🔍 New /fh catalog Command in Slack

Search, view, and manage your catalog items directly from Slack! This new command brings the power of your FireHydrant Service Catalog right to your fingertips:

• Search Service Catalog items with real-time filtering
• View detailed item information including descriptions, ownership, and change events
• Add or remove items as incident impacts without leaving Slack
• See recent Incidents involving specific Service Catalog items
• Access ownership information and external links
• Quick links to view items in FireHydrant

⚠️ Enhanced Schedule Management

We've improved the on-call rotation schedule experience with better warnings and controls when making changes, ensuring you know exactly what is changing and when.

• Clear warnings when modifying shift rotations
• Choose when the changes will take effect – Next Handoff, Now, or Custom timing
• Side-by-side comparison of current vs new rotations
• Displays timing information for each shift

⏰ High Priority Notifications Warning

To help prevent missed critical alerts, we've added a warning that lets you know when you haven't configured immediate notifications for high-priority alerts. This ensures you're making informed decisions about your notification setup and have no delays in your response to critical issues.

🐛 Bug Fixes

• We fixed an issue with the /fh update command in Slack which sometimes made it difficult to fill out missing required fields when moving to a new milestone
• Fixed a bug in the /fh page that was preventing users from paging a service when no specific user or team was defined

Hey there, Firefighters 🧑‍🚒 Here’s what we’ve shipped for your this week:

🚨 Page from Anywhere in Slack!

The /fh page command now works from any Slack channel – you're no longer restricted to incident channels. This makes it easier to page on-call teams whenever and wherever you need to.

📅 Add Non-Team Members to Signals Schedules

Sometimes you want to add people to Signals schedules who might not be a part of your FireHydrant Team – now you can! Easily add people to on-call schedules even if they're not part of the team, providing more flexibility in your schedule management.

📃 Export CSV Reports of On-Call Hours

We’ve added the ability to export CSV reports of on-call hours, filtered by users and time periods and grouped by user. Especially helpful for our EU customers, this feature helps track and manage on-call hours per user over specific time periods along with data about the number of pages that each person received.

⚒️ Webhook Enhancements

We've enhanced incident webhooks with more milestone information, including each milestone’s ID, name, and organization-level milestone ID for better cross-referencing.

🎨 UI Improvements

• You can now link directly to specific events in your Signals event log, making it easier to share and reference particular incidents.
• We’ve upgraded our date range components to be easier to use and faster for people that are used to time range selectors in logging tools.
• We’ve Added an “x” to the Due Date field in Tasks so you can easily remove dates. This update applies globally across the application to all fields with a timepicker.

🐛 Bug Fixes

• Fixed a bug in Signals that was causing crashes when event logs contained attachments
• We've improved timezone support for calendar integrations – your Outlook calendars will now correctly display on-call schedules in the right timezone
• Fixed a bug that was causing the final window of some weekly on-call shifts to be dropped under rare circumstances
• Fixed an issue where team tags weren't displaying the correct team name on catalog pages

Hey there, Firefighters 🧑‍🚒 Check our what we’ve shipped for you this week, including more flexible organization settings, improved /fh help commands in Slack, more Status Page flexibility, and more. Check it out 🚒

⚙️ Organization-wide Settings

Take more control of your FireHydrant experience with new organization-wide settings:

Weekly Email Preferences: Choose whether your team receives "Last Week in Incident Response" emails

Timezone Management: Set a default timezone for your entire organization (excluding Slack interactions)

💬 Improved Slack Commands

We've revamped our Slack Help command (/fh help) to make it more intuitive:

• All Signals commands are now included
• Updates to descriptions and titles for greater clarity and organization
• New categorization and updated titles, along with helpful emojis

📖 Milestone Management in Runbooks

For incidents that don’t require a retrospective, it can be easy to forget to change the state of an incident to “Closed.” Within the “Update incident details” runbook step, you will now see the Milestone for “Closed,” enabling you to automate the process of closing out resolved incidents, triggered by time lapsed or other criteria. This ensures no incidents get left in the “Resolved” state and you can more accurately track your incident activity.

📊 Status Page Flexibility

You can now add resolved incidents to your status page, promoting greater transparency with your customers by providing both an accurate record of past issues and how issues have been resolved.

📱Call Route Escalations

It happens – the primary contact isn’t always available at the right moment. Call Routes now support escalation steps when using Direct Connect mode, ensuring the critical call won’t go unanswered. If the primary contact is unavailable, the system automatically tries backup contacts with customizable timeout intervals.

🛠️ Other Improvements

• Within Analytics, you can now click into the list of Incidents that have “No value set” for custom fields
• Google Calendar integration now handles bot-created incidents more gracefully
• Enhanced webhook delivery reporting with more detailed data and failure information
• Improved navigation highlighting and consistent table headers throughout the UI
• The mobile app now displays tags in the alert detail screen
• The mobile app now prompts you if you are missing notifications for the current device
• In addition to updating to the closed state in runbooks, incidents can now be filtered based on when they were closed

🐛 Bug Fixes

• Fixed an issue where status messages were occasionally double-posted in incident channels
• Resolved a bug affecting keyboard usage in our iOS app when sending pages
• Fixed navigation highlighting issues on the Settings page
• Addressed webhook delivery inconsistencies

Stay tuned for more updates! We're always working on making incident management smoother and more efficient for your team.

Hey there, firefighters. 🚒 Here's what shipped this week:

🔊 Customizable Alert Sounds & Volume

We know that one alert tone doesn't fit all situations – or all responders. Now you can personalize both how and how loudly FireHydrant gets your attention when paging you.

• Sound Customization
  • Choose from a curated selection of notification sounds to match your preference
  • Set custom volume levels for pages needing your attention
  • Preview sounds and volume levels before selecting them

No more scrambling to adjust your phone's volume during an alert storm – customize your alert experience exactly how you want it, when you want it.

📅 Schedule Management Improvements

Making it easier to manage your on-call schedules with new filtering and organization tools.

• Schedule Filtering:
  • New "My Shifts" filter to quickly find your assignments
  • Bulk select/deselect all schedules with one click
• Slack Integration Updates:
  • We updated our Slack user group sync functionality to post informative messages on team’s Slack channel when we’re unable to add on-call users to a user group and are instead forced to disable it.

📋 Runbook & Alert Enhancements

New ways to organize and track your incidents and alerts.

• Runbook Organization:
  • Sort runbooks by name, last update, or creation date
• Alert Visibility:
  • Clear indication of manually paged alerts
  • Enhanced alert context in notification displays

🛠️ Jira Integration Improvements

Better Jira ticket management for your incidents:

• Fixed custom "Labels" field mapping in Jira Cloud issue creation
• Better error handling for field mappings
• Smoother ticket creation workflow

📨 Email Event Handling

Improved flexibility in handling email-based alerts:

• Support for generic email events without specific targets
• Redesigned form layout for clearer rule configuration
• Better visibility of targeting options

We're constantly working to make FireHydrant the best incident management tool out there. Stay tuned for more updates, and keep that feedback coming.

Hey there, firefighters. 🚒 It’s been a busy week here! Here's what we shipped for you:

⏰ Team Support Hours

Take control of your alert management with intelligent support schedules that automatically adjust notification priorities based on your team's availability.

• Customizable Team Schedules:
  • Define working hours for each team
  • Set support availability windows
  • Manage notification delivery based on schedule
  • View any teams support hours anywhere across the application
• Smart Alert Routing:
  • Automatically respect maximum notification priority during support hours
  • Honor team escalation policies
  • Control alert flow based on team availability

📱 Interactive iOS and Apple Watch Notifications

Respond to alerts faster than ever with our new interactive notifications for iOS and Apple Watch users.

• Quick Actions from Notifications:
  • Acknowledge, Escalate, Resolve, or Ignore alerts without opening the app
  • Perfect for Apple Watch users managing alerts on the go
  • Immediate feedback on your actions with follow-up notifications
• Enhanced Navigation:
  • Deep links take you directly to alert details after action
  • Preserve context even when errors occur
  • Seamless integration with existing alert management workflows

📚 New API Documentation

We've launched our new developer documentation to help you build powerful integrations with FireHydrant. As developers, we wanted to release something we would want to use ourselves. Check it out here!

• Complete API Reference:
  • Comprehensive endpoint documentation
  • Real-world example requests and responses
  • Interactive API explorer for testing endpoints
• Better Developer Experience:
  • Clean, modern interface for easier navigation
  • Detailed authentication guides
  • Code samples in multiple languages

📋 Enhanced Error Logging in Signals

You told us that finding and resolving Signal errors could use some love from us – and we agree. Now, with our redesigned error logging system, you'll spend less time hunting for information.

• Persistent Error Storage:
  • Never lose critical error information from Signals parsing
  • Share error context (headers,, request context, etc) easily with team members and stakeholders
• 5x More Efficient Log Display:
  • Find relevant information faster with denser, cleaner displays
  • See more context with consistent cursor
• Smart Error Context:
  • Diagnose issues faster with complete error context
  • Reproduce issues more easily with full request details

🛠️ UI Improvements

Small changes that make a big difference in your daily workflow.

• Task Context Display:
  • Prioritize work more effectively with complete incident context
  • Reduce confusion around auto-assigned Runbook tasks
  • Track task progress with full visibility into related incidents
• Table Interactions:
  • More intuitive hover states and click behaviors reduce cognitive load
  • Consistent interaction patterns across the platform
  • Clearer visual feedback for all actions
• Performance Optimization:
  • Get answers faster with improved query response times
  • Work confidently with more reliable data loading
  • Handle complex investigations without performance degradation
• Priority Notification Settings in Mobile:
  • Set notification preferences for all priorities directly in the mobile application
  • Quickly understand how you’ll be paged based on inbound priority directly in the application

We're constantly working to make FireHydrant the best incident management tool out there. Stay tuned for more updates, and keep that feedback coming.

Hey there, firefighters. 🚒 Here's what shipped this week:

🚨 Signals Improvements

Make your on-call schedules work the way your team does. We've added more flexibility to match your preferred calendar view and management style.

• Custom Start Day: Choose which day your week starts, just like in Google Calendar
• Customize Event Source Targets: Target individual users, schedules, and escalation policies with custom transposers right from the teams page
• Better Filtering: Enhanced team filtering and organization for improved schedule management
• Generic Email Ingestion: Now emails can be treated as generic inbound events, like any of our other sources. With this change, emails can be actioned by rules rather than needing a predefined target.
• Email attachments are now captured: When you send FireHydrant an email to trigger an alert via email ingest, we’ll now also capture any attachments included in the email and give responders a link to download them.

📊 New Team Analytics

Get deeper insights into your team's operational performance with expanded analytics:

• Alert Analytics: View alert metrics directly on team pages alongside incident data
• Performance Metrics: Track total opened/acknowledged alerts and incidents
• Visual Insights:
  • Better MTTX data visualization
  • New alert funnel progression
  • Temporal heatmaps
  • Team-specific filtering

🌐 Mobile App Enhancements

We've also introduced better notification handling and navigation across all devices:

• Shift Overrides: Now you can override shifts just as easily as requesting coverage directly in the mobile app
• Android Improvements: Fixed push notification handling. Now when you tap on a push notification, we will navigate you to the correct alert detail screen
• Alert Timeline Improvements: Now alert timelines will load immediately when navigating to an alert from a push notification.

⚙️ Custom Field Improvements

Expanding on our custom fields implementation, we've made incident management more flexible for enterprise needs:

• Expanded Limit: Increased custom field limit to 30 for Enterprise users
• Timezone Clarity: Added explicit timezone information to incident resolution time inputs to reduce confusion for users across different timezones
• Better Context: Improved task context display in the My Tasks widget

💡 UI/UX Improvements

We’re continuing to make FireHydrant easier and more intuitive to use. Some quality-of-life items we’ve shipped:

• Clearer Team Labels: Updated "Impacted Team" to "Service Owning Team" throughout the platform for better clarity that aligns with the service catalog
• Attachment Access: Easier access to email attachments and voicemail recordings is here! These can be now downloaded directly from the UI
• Task Context: Enhanced visibility of incident details and dates in task views

🐛 Bug Fixes

• Fixed a bug where you couldn't update the execution state of a runbook step manually in the UI
• Improved query handling for task context display
• Enhanced team filtering and analytics data loading

We're constantly working to make FireHydrant the best incident management tool out there. Stay tuned for more updates, and keep that feedback coming.

Hey there, firefighters! 🚒 We’ve had a busy week working on a lot of new features and enhancements to make your incident management experience better. Here's what shipped in the past week:

📞 New: Live Call Routing in Signals (Beta)

Expand your incident response channels and ensure critical calls never go unanswered. With call routing, you can now manage phone-based alerts directly within FireHydrant, streamlining your communication channels and reducing tool switching during incidents.

• Support for up to 5 active phone numbers per organization on Enterprise
• Two routing options:
  • Voicemail: Async communication with transcript and recording storage
  • Direct Connect (Beta): Forward calls directly to team members

🔄 Signals and Integration Updates

• Generic Email Targets for Signals: Create email sources without specific targets for broader team rules, perfect for managing department-wide or non-specific alerts
• Weekly Summary Emails: Improved visibility into your recent incidents from the previous week, removing the previous 20-incident limit.
• Weekly email summaries now have support for custom milestones and customized MTTX metrics right in your inbox.

🐛 Bug Fixes

• Fixed required fields validation when archiving incidents, streamlining the cleanup process
• Improved tag list population in Slack's /fh update command, making incident updates more efficient
• Enhanced Azure SCIM update processing for smoother user management
• Fixed latency issues on schedule page, providing faster access to on-call information
• Improved command handling for accounts with multiple organizations in Slack Enterprise Grid
• Fixed catalog listing when GitHub integration is uninstalled, ensuring stable operation even when integrations change

💅 Other Improvements

• New endpoint to retrieve single users by ID (GET /v1/users/:id), enabling better user management in custom integrations
• Added tag options support to the /fh update command, making incident updates more comprehensive
• More intuitive service command labels for responding teams, reducing confusion during incident response
• Any owner can now reauthorize integrations, not just the original authorizing owner
• Chat channel links now display on automatic pages from catalog item additions, improving navigation between related resources

Hey there, firefighters. 🚒 We've been hard at work improving FireHydrant to make your incident management even smoother. Here's what's new:

🎉 New Features and Major Improvements

⏱️ New Required Milestone Timestamps

We've introduced a powerful new feature to enhance your incident tracking: required milestone timestamps. Now with each milestone you can:

• Ensure that all incident milestones are set before allowing you to resolve an incident
• Ensure that custom post incident milestones are set in order to finish a retrospective
• Ensure that all alerting milestones are set to get more accurate metrics

📱 Mobile App: New Alert Timeline and UX Improvements (v0.13.0)

We have a brand new, comprehensive, chronological display of alert events on mobile, including creation, rule matching, and subsequent actions.

We include information about who acknowledged, resolved, or ignored an alert at the top of the screen. Additionally, we display the entire alert timeline to investigate how an alert escalated over it’s entire lifecycle.

Other mobile improvements include:

• Global Swipe-to-Refresh: Refresh the entire screen with a single swipe to catch up on the latest alerts in your organization
• Adaptive layouts: Better layout across all device sizes
• Manual Paging Info: New field shows who initiated manual pages.

These are all available today in iOS and Android.

🔗 MS Teams: Incident Type Selection and Milestone Transitions

Exciting new developments in MS Teams: you can now pick incident types in an easy-to-use dialogue, streamlining the amount of time it takes to fill out important fields and impacted components.

• Pick incident types when declaring incidents.
• Dialog-based interactions for less disruption in common channels.
• Modal for handling required fields when transitioning milestones.

💬 Slack: Enhanced /fh update for required fields and Link Handling

Not to be left behind by MS Teams, we also have several new improvements for Slack and required fields.

• Improved /fh update command: Slack modal now updates with inputs for missing required fields when selecting a new milestone.
• Embedded links in messages are now visible and clickable in the incident timeline.

📊 New Timeline CSV Export

• Download your entire incident timeline as a CSV file, including timestamps, authors, and event summaries.

🛠️ Other Improvements

• Alert Actions: New layout for acknowledgment and resolution information.
• Settings Button: Increased touch target size for better accessibility.
• Task List Reordering: Fixed drag-and-drop functionality in settings.

🐛 Bug Fixes

• Fixed navigation bugs in the alerts screen.
• Resolved issues with runbook step execution after manual termination.
• Fixed filtering of null users in Signals calendar.
• Various improvements to runbook closure and step dismissal processes.

🚀 What's Next?

We're constantly working to make FireHydrant the best incident management tool out there. Stay tuned for more updates, and keep that feedback coming.

Enhanced On-Call Scheduling in Signals

We've improved the flexibility and accuracy of on-call scheduling in Signals, allowing for more complex rotation patterns and intentional coverage management.

Key Features and Benefits

• Users can be added to rotations multiple times, enabling more flexible schedules.
• Schedules can now include intentional gaps in coverage, supporting irregular patterns.
• Better visualization of intricate rotation patterns and complex schedules.

Why It Matters

These enhancements allow you to create schedules that truly reflect your team's availability and preferences, managing coverage more effectively, including planned gaps.

Getting Started

No additional configuration required. Signals users can start creating more flexible and accurate on-call schedules immediately.

Webhook-based Notifications for Signals

We've introduced a new webhook target management feature in Signals, enabling automated alert notifications to your preferred destinations without the need for incident escalation.

Key Features and Benefits

• Dedicated webhook management interface in the Signals sub-menu
• Target webhooks in escalation policies and "Page people via Signals" runbook step
• Send alerts to custom webhook destinations without unnecessary escalation
• Increased flexibility in choosing notification destinations for each Alert
• Improved integration with your team's preferred communication tools

Why It Matters

This enhancement bridges the gap between our existing webhook capabilities and the need for targeted, customizable alert notifications, allowing for more effective team communication and faster response times.

Getting Started

Access this feature in the Signals section to create and configure webhook targets for your alerts. When setting up or editing an alert, you can now select a webhook for automated notifications.

Customizable "Closed" Lifecycle Phase

Enterprise customers can now customize milestones in all four incident lifecycle phases, including the "Closed" phase, providing complete control over your incident management workflow.

Key Features and Benefits

• Full customization of the "Closed" incident lifecycle phase.
• Tailor the entire incident lifecycle to match your organization's specific processes.
• Maintain consistent workflows even after an incident is closed.
• Improve post-incident activities and learning processes.
• Enhance reporting and analytics with customized closed phase data.

Why It Matters

This update allows you to define and track post-incident activities crucial for your team's learning and improvement processes, addressing the unique needs of your organization in handling closed incidents.

Getting Started

Enterprise customers can access these new customization options in the "Incident Milestones" settings.

Improvements

💅 Email event sources got an upgrade. You'll see separate Signals and alerts for each valid recipient. This means more accurate targeting for your notifications.

💅 We’ve added the ability to download the incident timeline as a CSV. This CSV export includes the timestamp, author, and summary of each event, giving you a comprehensive overview of the incident's progression.

💅 We've added support for custom milestone mappings to ticket states in Linear, allowing for more flexible incident management workflows.

Bug Fixes and Optimizations

🐛 Fixed a bug preventing the re-use of names of deleted Measurement Definitions.

🐛 Resolved an issue preventing the creation of a new Healthiness Measurement after an organization's existing one had been deleted.

🐛 Fixed a bug causing pending runbook steps to execute even if the runbook was canceled.

🐛 Corrected Nunc Status Page URLs to properly link directly to the incident instead of the general status page.

Flexible Milestone Ordering

Chronological order for milestones is no longer required. We've removed this constraint to give you more flexibility in recording incident timelines as they actually unfold.

What's New

• We now allow for out-of-order timestamp entries.
• Negative durations between milestones are now possible we automatically exclude them from analytics.

Benefits

• Greater flexibility in recording incident timelines.
• More accurate representation of complex or unusual incident scenarios.
• Improved ability to capture real-world incident management processes.

Why It Matters

In the dynamic world of incident management, processes don't always follow a perfect, linear path. This update acknowledges that reality and provides the tools to accurately record and analyze incidents as they truly unfold. By allowing out-of-order milestones, we're enabling more precise and honest incident documentation.

Getting Started

No special configuration is needed to use this feature—it's automatically available for all incidents. We encourage you to leverage this flexibility to create more accurate and detailed incident records.

Adaptive Required Fields for Incident Milestones

We've enhanced the incident update process in our web UI to ensure all critical information is captured while maintaining a smooth user experience. This new feature introduces an adaptive approach for handling required fields when changing incident milestones, making it easier to manage incidents effectively.

What's New

• A modal now appears when transitioning an incident's milestone, displaying any unfilled required fields.
• Required fields are intelligently presented based on the current and target milestones.
• Changes are preserved and applied after required fields are filled.

Benefits

• Smoother workflow for updating incident status.
• Prevents data loss and ensures all necessary information is collected.
• Improves data completeness for incident documentation and analysis.

Why It Matters

By adapting to each milestone's requirements, this system streamlines the update process while guaranteeing that all essential information is recorded. This leads to more comprehensive incident documentation and smoother handoffs between team members.

Getting Started

To use this new feature, initiate a milestone change for an incident as usual, and the system will guide you through providing any required information specific to that milestone or previous milestones.

Enhanced MTTX Analytics

MTTX Analytics now provides metrics for incident milestones, allowing you to explore data for each milestone in greater detail. Additionally, we've migrated task and follow-up progress metrics to the MTTX Analytics page, consolidating all your incident-related metrics in one place.

What's New

Milestone Metrics for Incidents

• Drill down into individual milestone metrics within your MTTX Analytics.
• Available for various analytics dimensions including severity, services, and teams.

Task and Follow-up Progress Metrics

• Task and follow-up progress metrics are now integrated into the MTTX Analytics page.
• No more switching between different pages to access all your incident-related metrics.

Key Benefits

• Gain deeper insights into your incident lifecycle with granular milestone data.
• Analyze performance across different stages of your incident management process.
• Access a comprehensive view of your incident metrics in one centralized location.

Why It Matters

By bringing all these insights together, we're empowering you to make more informed decisions and drive improvements in your incident management practices.

Getting Started

These enhancements are automatically available to all users with access to MTTX Analytics.

Improvements

💅 MS Teams Integration: We've officially removed the "Beta" label from our MS Teams integration. It's now generally available to all users!

💅 User CSV export now includes assigned teams. Users can now run automations or pull analytics based on team assignment data in the User table.

💅 We've added role display to the invitations list in the main UI and included an initial role selector in the new invitation form. You can now invite team members and assign a them a role.

💅 Updated behavior of viewing service dependencies and change events in Slack to maintain context.

💅 Enhanced /fh service Slack command for improved service management. Users can now view service info, mark services as impacted, and manage dependencies more easily directly from Slack, enabling faster and more intuitive service operations.

Bug Fixes and Optimizations

🐛 Non-Owner user roles can now filter the incident list by a custom field.

🐛 Fixed an issue preventing filtering by “Incident Type in analytics.

🐛 Fixed an issue in Chrome where UTC option for timezones in the schedule creator were not showing.

Team-Wide Paging: Escalation Policies Evolve

We're excited to introduce a powerful new option for escalation policies: the ability to target all members of a team simultaneously.

What's New

• Escalation policies can now target an entire team at once
• Provides an alternative to the team's default escalation policy
• Acts as a "pull the fire alarm" feature for urgent situations

Benefits

• Increased flexibility in team paging
• Potential for faster response times
• Simplified process for alerting entire teams

Why It Matters

This highly-requested feature reinforces our commitment to "team-first" paging. By allowing you to page all team members with a single action, we're making it easier than ever to mobilize your entire team during critical incidents.

Whether you're dealing with a major outage or need all hands on deck, this feature ensures that no one is left out of the loop when every second counts.

Getting Started

To use this new feature, simply update your escalation policies to target the desired team. For more detailed instructions, check out our updated documentation.

Automated AI Summaries in Liquid Snippets

We're thrilled to introduce AI summaries to our liquid snippets list, bringing intelligent automation to your incident communication process.

What's New

• AI summaries are now available in the liquid snippets list
• Automate summary generation based on runbook conditions
• Post AI-generated summaries directly to Slack or MS Teams

Benefits

• Save time by automating summary creation
• Ensure consistent and intelligent incident reporting
• Streamline communication to team collaboration tools

Why It Matters

This feature significantly enhances your ability to keep teams informed during incidents. By automating the creation and distribution of AI summaries, we're reducing the manual effort required in incident communication while ensuring that all stakeholders receive timely, coherent updates.

Whether you're managing a minor hiccup or a major outage, this feature ensures that your team stays informed without adding to your workload.

Getting Started

To leverage this new feature, simply configure your runbook conditions to trigger AI summaries and set up the integration with your preferred collaboration tool (Slack or MS Teams).

Improvements

💅 We've added a new slash command alias for /fh signals-on-call. You can now use /fh signals-oncall, accommodating different spelling preferences and helping you access the command faster.

💅 Hovercards have been added to various locations throughout the UI, enhancing the user experience and providing quick access to relevant information.

💅 The on-call schedule page will now remember your previously selected view, you no longer need to switch between our default weekly calendar view and your preferred display.

💅 Interacting with status pages got a big overhaul in the web application. Now we’ll allow you to verify that an incident name is correct before posting it to a status page, we will warn you when you’re making an update to a publicly accessible page, and more.

💅 On the Users list, we now include information about the teams to which those users are assigned.

💅 Adds a new column to the incident CSV export for unassigned teams. Now the CSV data will differentiate between actively assigned teams and no longer assigned teams in that data set.

💅 Alerts created manually through our API and applications are now tagged with annotations, making it clearer who created each alert.

💅 The alerts section on the incident page now allows you to attach additional alerts to the incident without needing to go to a separate tab.

💅 The incident settings page now includes an estimate for how long we think it will take someone to declare an incident. This will help you understand how the fields you require impact the cognitive load of a responder at declaration time.

💅 We've added support for custom milestone mappings to ticket states in Jira On-Prem, allowing for more flexible incident management workflows.

Bug Fixes and Optimizations

🐛 Fixed an incorrect tooltip link in the impact stats table, now pointing to our updated documentation.

🐛 Fixed an issue with searching saved views if an organization had more than two hundred saved views.

🐛 Fixed an issue where some Slack channel inputs were not searchable in alert routing.

🐛 Fixed an issue where organizations needed to manually choose a healthiness calculation, it is now selected by default.

🐛A large number of tables got a visual refresh to be better aligned and more clear in the information they are showing.

Cortex Integration

We're pleased to announce the integration of Cortex with FireHydrant. This new feature allows you to import Catalog entities from Cortex directly into FireHydrant, streamlining the management of your microservice ecosystem. Additionally, you can now synchronize team and service information between the two platforms, ensuring consistent and up-to-date data across your tools.

This integration enhances your ability to leverage Cortex's comprehensive service catalog within the FireHydrant environment, improving visibility and coordination in your microservice management and incident response workflows.

What this means for you

Simpler service management - by importing Cortex Catalog entities into FireHydrant, you can manage your microservices from a single platform, reducing complexity and saving time.

Faster incident response - with up-to-date service information readily available in FireHydrant, your team can quickly identify affected services during incidents, leading to faster resolution times.

Better team collaboration - synchronized team and service data ensures that all stakeholders have access to the same information, facilitating better communication and coordination across departments.

Less manual work - automatic synchronization between Cortex and FireHydrant eliminates the need for manual data updates, minimizing errors and ensuring data accuracy.

Big picture view - by combining Cortex's service catalog with FireHydrant's incident management capabilities, you gain a comprehensive understanding of your microservice ecosystem and its performance.

Teams can significantly improve their operational efficiency, reduce mean time to resolution (MTTR) for incidents, and maintain a more robust and reliable microservice infrastructure through this powerful integration.

To learn more about the Cortex integration, check out the documentation.

Mobile Dashboard

We've given our iOS and Android apps a fresh new look with a home screen that puts everything you need front and center. You'll see your on-call status at a glance, plus quick access to recent alerts, active shifts, and coverage requests. We've also streamlined navigation, making it easier to find what you're looking for.

What this means for you

Manage alerts, check shifts, and handle coverage requests with fewer taps, making your work smoother and more efficient.

With this update, we're making your on-call life a little bit easier. Enjoy the new dashboard!

Head over to the App Store or Google Play Store now and download the latest version of our app.

Other Improvements and Bug Fixes

💅 You'll now see custom measurement definitions displayed in the services, functionalities, environments, and teams pages. Instead of hardcoded headers and data, the tables now dynamically pull information from the API response, giving you a more accurate and tailored view of your metrics.

💅 When publishing a retrospective, you can choose a specific milestone to associate it with. Additionally, you'll see a handy "Download PDF" button when viewing a retro. This allows you to easily share the retrospective with your team or stakeholders.

💅 We've polished up our incident status templates in Slack for a smoother user experience. Now, instead of seeing raw Liquid code, you'll see the fully rendered template in your incident updates. This change ensures that your status updates are immediately clear and readable, without any distracting code snippets.

💅 We've streamlined our example placeholder for custom event sources. While we previously showcased a comprehensive function to demonstrate the full power of JavaScript, we realized a simpler approach could be just as effective. The new, more concise example includes helpful comments, providing a clearer starting point without overwhelming our users.

💅 We've enhanced our API to help you stay in the loop about your team's notification preferences. Now you can programmatically check if your teammates have enabled Signals notifications, including push and email alerts. This API update gives you better visibility into how your team is staying informed, helping you ensure everyone's on the same page when it comes to important alerts.

💅 We've standardized the naming of follow-ups across our platform. This update ensures consistency and clarity in how we reference them moving forward.

💅 We've improved the readability of runbook rows by wrapping text in the category cell. This small but impactful change helps you see full category names at a glance, making your runbooks easier to navigate and understand.

🐛 We've updated our change events API to play nicely with our catalog entries. Now, you can use friendly ID slugs for services and environments when creating change events. This fix to the POST /v1/changes/events endpoint makes it easier to associate services and environments with your change events.

🐛 We've squashed a bug that was getting in the way of filtering resolved alerts by team. We now check for both the alert's Team and the associated Alert Trigger for team information. This means you can now easily find all resolved alerts for a specific team, giving you a clearer picture of your alert history.

🐛 We've fixed a bug that was blocking you from reusing names of deleted Severities and Priorities. You're now free to create new ones with those familiar names, giving you more flexibility in organizing your work.

🐛 We've patched an issue with our Slack framework that was giving some customers trouble with the /fh new command. We've gone through the framework and added additional label truncation to resolve this issue.

🐛 We've updated how we display the configured or unconfigred tag on the project table for users who have custom milestones. This change comes after implementing custom milestones. Now, to be marked as "configured," both the incident default issue type and the first milestone need to be set.

🐛 We've squashed a couple of bugs on the teams page related to our custom milestones feature. You'll now see correct tooltip names instead of the old ones that were hanging around. We've also fixed how column data is passed to the charts, so they should be displaying accurately now.

🐛 We've fixed a tricky bug related to incident milestones. Previously, incidents could end up with an invalid "started" milestone if you had customized your milestone setup. Now, when an incident is created, we ensure it's assigned to the first valid milestone in your organization's configuration.

🐛 We fixed a bug that was giving some users trouble with hiding the "Priority" field. You should now be able to customize your incident form fields as intended, including hiding the Priority field if desired.

🐛 We've fixed a bug that prevented users from reopening incidents with required impact fields. The issue stemmed from a recent change related to custom milestones, which inadvertently caused all impacts to be removed when re-opening an incident. Now, you can smoothly reopen incidents even when services, functionalities, or environments are set as required fields.

🐛 Some users were running into issues when trying to resend an invitation that had failed initially. We've updated our system to skip the unique email check when resending invites, so you should now be able to get those invitations out without a hitch.

🐛 We've rolled out a bundle of improvements to enhance your alert analytics experience. We've fixed filtering issues on alert attributes, refreshed the heatmap colors for better visibility, and made several UI enhancements to the alert analytics page, including more accurate links and improved chart displays.

🐛 We've streamlined the incident closure process for a smoother user experience. Now, when you submit a close request, the modal will automatically close, giving you instant feedback on your action.

🐛 We've improved navigation for project pages. Now, if you try to access a non-existent project, you'll be automatically redirected to the main projects page, ensuring you always land in a useful spot.

🐛 We've updated the alert modal to be more intelligent in displaying linked incidents. If an alert has no linked incidents, we will now assume that there are no linked incidents to show in the alert modal's link view.

Custom Milestones

We've updated our Milestone feature with customization options! Now you can tailor your incident management process to perfectly fit your organization's unique needs. Seamlessly align Milestones with your specific policies and workflows for a smoother, more efficient experience.

Curious to learn more? Check out our blog.

Field Requirements for Milestone Transitions

We've enhanced our milestones feature. You can now set field requirements at each milestone transition, enabling:

• Specified required fields for individual milestone stages
• Improved compliance tracking throughout the incident lifecycle
• Greater flexibility to match your organization's policies

This update addresses customer requests for more granular control over incident progression. It's incident management, your way!

For configuration details, please refer to our documentation.

Other Improvements and Bug Fixes

• 💅 We've added a powerful new attribute to runbook steps. You can now create conditional execution based on changes in incident details (Name, Description, Severity, Priority, Milestone, Impacted Infrastructure). This enables more precise and dynamic incident response automation. Remember to check Rerun on every transition if you want this step to execute on every change to said details!

• 💅 We've enhanced validation for required fields in incident management, ensuring they're checked consistently throughout an incident's lifecycle, not just at declaration. This improvement covers both standard and custom fields. We've also refined error messages for failed updates, providing clearer feedback when required information is missing or incomplete.

• 💅 We've added a timeline view to on-call schedules, displaying each calendar as a row with shifts color-coded by user. This new view offers a quick overview of your team's availability, making it easier to spot patterns and coverage gaps. Check it out in the on-call schedules section to streamline your scheduling process.

Associate alerts to incidents from Alert detail pages

Now you can associate alerts to incidents directly from the Alert detail pages. This new functionality makes it easier to link relevant alerts to ongoing incidents, streamlining your workflow.

What does this mean for you?

• Improved efficiency - less time spent navigating between pages
• Better context - all the information you need in one place
• Easier tracking - quickly see connections between alerts and incidents

This update allows for quicker and more intuitive alert-incident association, supporting more comprehensive incident documentation and analysis.

Other Improvements and Fixes

• 💅 Our MS Teams integration is now generally available. Seamlessly connect your incident management workflow with your team collaboration hub.

• 💅 We've added a visual "Now" indicator to your team's on-call calendar. Quickly spot the current time and see who's on duty at a glance.

• 💅 We've upgraded your schedule view! Upcoming shift start times are now displayed right in the interface. Quickly see when you're on next, keeping you prepared and on schedule.

• 💅 Our Signals org-wide on-call endpoint is now public. Easily connect external systems to access your organization's on-call information, opening up new possibilities for custom integrations and workflows.

• 💅 Great news for Jira on-prem users! You can now post incident updates directly to your Jira on-prem tickets from FireHydrant. Keep your entire team in the loop with seamless incident status updates across both platforms.

• 🐛 We fixed a bug in our iOS app that was blocking some users from using the keyboard when sending a page.

• 🐛 The schedule page will no longer automatically scroll to the middle when loading. Enjoy a more intuitive browsing experience as you check your on-call schedule.

• 🐛 We've fixed a bug that was blocking custom date/time fields in alert routing. Now you can use these fields to create more precise and flexible routing configurations.

• 🐛 We've fixed a sneaky bug that was hiding shifts with midnight turnovers. Now you'll see all your shifts, no matter when they start or end.

• 🐛 We fixed a bug that prevented the "Invite Scribe to Incident" step from being repeatable. Now you can repeat this action as needed, ensuring your scribe is always available – even for long-running or reconvened incidents.

Create incidents from Slack emoji reactions, including incident types

We've added the ability to create incidents directly from emoji reactions in Slack. This feature also supports specifying incident types during creation.

Key details:

• Users can now trigger incident creation by reacting to Slack messages with customizable emojis
• Incident types can be specified as part of the emoji-based creation process
• Streamlines the incident creation workflow within Slack

Benefits:

• Faster incident reporting
• Increased flexibility in how incidents are initiated
• Improved integration between Slack communication and incident management

How it works:

• Specific emojis can be configured to trigger incident creation
• Different emojis can be set up to create incidents of various types
• Reacting with a designated emoji automatically starts the incident creation process

This feature enhances the seamless integration between everyday communication in Slack and our incident management system, allowing for quicker and more intuitive incident reporting.

To learn more, view our documentation

User Interface Improvements

We are excited to roll out several UI improvements aimed at enhancing the user experience across various screen sizes and improving clarity in several areas of our application. Here’s a breakdown of what’s new:

Incident Types

• Preservation of Existing Names: Existing incident type names are no longer overwritten when loading.
• Terminology Update: The 'name' field has been changed to 'incident name' in the incident settings page for better clarity.
• Responsive Design: The incident settings page now boasts enhanced responsiveness, with the last few fields wrapped in an elegantly designed card.

User Account

• SSO Account Display Email: We've added a read-only display email for SSO account users, making it easier to identify your account details.
• Mobile Responsiveness: The user account page is now fully responsive on mobile devices, ensuring a seamless experience on the go.

Slack Configuration

• Improved Spacing and Mobile Responsiveness: We've made adjustments to improve spacing and ensure the configuration is user-friendly on mobile devices.

Filters

• Renamed Date Filters: For better clarity, date filters have been renamed to 'Started after' and 'Started before.'

Incident and Retro Pages

• Enhanced Mobile Responsiveness: Both the incident and retro pages have received updates to improve their mobile responsiveness and resolve any existing layout issues.

These updates reflect our ongoing commitment to improving the FireHydrant platform and making it more user-friendly for our valued customers.

Other Improvements and Fixes

• 💅 We've streamlined your mobile experience! You can now acknowledge or escalate alerts on iOS and Android without confirmation, allowing for quicker responses to critical situations. Update your app today to enjoy this time-saving feature.

• 💅 We've improved the way long conditions display in the Execution Rules section. Now, all text wraps neatly, making it easier to read and understand your complex rules at a glance.

• 💅 Our AI just got more intuitive! Incident summaries now factor in the current milestone, giving you more relevant insights as your incident progresses.

• 💅 We've made the "Invite scribe to meeting" step repeatable, ensuring your scribe is always there when you need them.

• 💅 You can now use relative time for partial shift coverage. Need someone to cover "for the next hour"? Just type it in – no more calculating end times.

• 🐛 We've fixed a bug affecting MS Teams users. You'll now see all incident updates in your non-incident channels, even without a specific incident channel. Stay informed without the extra setup.

• 🐛 We've fixed a pesky bug that was blocking some reauthorizations. Now, entitlement checks only run for new integrations, not reconnections. Existing integrations will reauthorize smoothly, even if you've hit your limit.

• 🐛 We've fixed a bug that prevented users from deleting priority on the incident form. Users can now clear the priority field in incident forms. Just select the 'x' option in the dropdown menu.

Incident Types Improvements

We've enhanced Incident Types to provide more flexibility and utility:

1. Added configurable "Incident Name" field to Incident Types, as requested by users. This allows for custom naming conventions like "[Service]-[Date]-[Issue]".
2. Implemented filtering by Incident Type in both the UI and API.
3. Made Incident Types available in runbook conditions, enabling more targeted automation.
4. Introduced Incident Type filtering in analytics for improved reporting capabilities.

These updates allow for better pre-population and templating of incident declarations, making the process easier for responders.

Export Retrospectives to Google Doc with Full Permissions

Retrospectives exported via Google Doc integration are now created with edit permissions by default, eliminating the need to manually change permissions for each document. This update, based on user feedback, allows immediate team collaboration. Users can still adjust permissions as needed within Google Docs.

Other Improvements and Fixes

• 💅 Incidents can now be accessed by number instead of ID (e.g., /incidents/123 rather than /incidents/a1b2c3d4). This change simplifies the creation of incident links and improves ad hoc navigation. The previous ID-based system remains supported for backward compatibility.

• 💅 We've made it easier to create scheduled maintenance. Users can now add scheduled maintenance via the "Declare Incident" dropdown on any page, eliminating the need to navigate to a separate section.

• 💅 Added the ability to remove push notification devices from your account, helping to declutter notification options and enhance account security. Users can manage their Push Notification Devices under the Profile section, where they can remove old devices.

• 💅 Field mapping labels for follow-up tickets are now clearer. They display as "Follow-up priority" and "Follow-up tags", replacing the previous generic labels. This change improves user understanding when configuring integrations.

• 💅 Functionalities for incident response are now available on the team detail page. Users can add functionalities directly from this page.

• 💅 Added a striped left border for calendar shifts belonging to the user viewing the calendar. Users can now easily identify their own shifts at a glance

• 💅 Added a configuration option to allow or prevent non-users (Slack accounts without linked FireHydrant accounts) from opening incidents. This setting can be found in the Slack connection settings.

• 🐛 We fixed an issue where completing a retrospective incorrectly removed impacted services and functionality. Retrospectives now correctly retain all associated information upon completion.

• 🐛 We’ve implemented a fallback mechanism for Jira token expiration. When we encounter token expiry errors using a user-specific connection, we now default to the integration's user token. This change is automatically applied and should result in fewer disruptions when interacting with Jira. We're continuing to monitor the situation and may implement further improvements in future updates.

• 🐛 We've updated how "all day" shifts are displayed in our UI. Now, only shifts that start and end at midnight are shown as "all day." Partial day shifts are now displayed with their specific start and end times. This change improves the accuracy of shift representation and addresses user feedback about shift duration clarity.

• 🐛 Viewers can now claim shifts, expanding the capabilities of this role. When a coverage request is submitted, users with the viewer role have the ability to claim that shift. This change allows for more flexible shift management and quicker coverage of open shifts.

DateTime Custom Fields

We've enhanced our custom field functionality by introducing a new date/time custom field type. This addition offers greater flexibility and precision in incident reporting and management. Here's what you need to know:

• Users can now create custom fields that specifically accept date and time inputs.
• This feature is particularly useful for precise timing information related to incidents.
• DateTime custom fields can be added via the Incident Settings page.

New time-based filters in Analytics

We're happy to introduce new time-based filters in Analytics. You will now see Last Week, Last Month, Last Quarter, and Last Year options in the Date Range picker. These additional filters will make gathering data easier for reporting.

Other Improvements, Bug Fixes and Deprecations

• 💅 We have cleaned up the UI on our Catalog show pages. Improvements include better loading states and condensed header sizes.

• 💅 Users can now create global saved views and default views for incident timelines. This feature enables quick switching between different perspectives and configurations without the need to manually adjust filters and settings each time.

• 💅 The update incident and resolve incident buttons are now displayed in the command center header.

• 💅 We have added the ability to post updates into incident Jira tickets. This brings more incident status visibility to users who want to leverage both FireHydrant and Jira.

• 💅 Added relative time selection for task due dates (e.g., "due in 15 minutes"), with the option to switch to absolute time when necessary.

• 🐛 We addressed an issue with our OpsGenie integration in the fh page command. Previously, we were returning more users than Slack could display. We now limit the return to the first 100 users, matching Slack's display capacity.

• 💥 We have deprecated the Data Export integration and Data Export page from Analytics. All data is still available via API, webhooks, and other means.

Mobile Onboarding

We're thrilled to introduce our new step-by-step onboarding process for both iOS and Android apps. This user-friendly guide helps you unlock the full potential of FireHydrant right from the start. As a new user, you'll be guided through setting up essential features, including:

• Enabling notifications to stay in the loop
• Activating critical alerts for timely updates
• Adding FireHydrant as a contact for seamless communication

We're excited for you to experience the full capabilities of FireHydrant on your mobile device!

DataDog Event Source Changes

Starting August 12, 2024, we will treat any payload from DataDog as having an OPEN status, except for those marked as "Resolved."

Currently, we ignore payloads unless the status is Triggered or Resolved. This means that Warn/Re-Warn webhooks from DataDog are ignored by FireHydrant.

What we're changing

We will begin treating Warn/Re-Warn the same as Triggered.

Why we're changing it

This change is to align with the rest of our product behavior: any payload coming to FireHydrant is associated to either OPEN or CLOSE  alert.

What you need to do

If you would like for FireHydrant to only listen on "Triggered", please update your DataDog monitor to be explicit on when DataDog will send a payload to us:

{#is_alert} @webhook-FireHydrant-Signals {/is_alert}
{#is_recovery} @webhook-FireHydrant-Signals {/is_recovery}

Other Improvements and Bug Fixes

• 💅 Android app maximum volume reduced from 100 to 75
• 💅 Microsoft Teams now displays milestones in notification cards
• 💅 Assigned teams is now available in CSV export
• 💅 Added a runbook condition for re-running steps whenever a status update is made
• 💅 Added the ability to disable announcing new incidents back to the channel when created via /fh new in Slack
• 🐛 We no longer announce private incidents in their originating channels
• 🐛 Fixed an issue where saving content on the Lessons Learned tab would sometimes return stale data.
• 🐛 We fixed an issue that may have caused us not to cache Slack channels properly in Enterprise Grid
• 🐛 Fixed a UI bug that prevented related services from being associated to a functionality in our Catalog
• 🐛We added back the ability to unsubscribe from weekly summary emails for non-Signals users

Custom Event Sources

We've released Custom Event Sources! Signals now has the flexibility to ingest and parse alert payloads from any observability tool in your stack and provide you the ability to configure alert notifications that best suit your teams needs.

With this update, regardless of the format of your payload, you can now include a simple snippet of your own JavaScript to transform it into a useful and beneficial format for your on-call teams.

To learn more, visit our blog post.

iOS Updates

You can now create and send Alerts from your mobile application. Send an alert/page to any user, escalation policy, on-call schedule, or team from your phone.

Other Improvements and Bug Fixes

• 💅 We've improved our notification system to ensure you never miss an alert. Fallback notifications (email and Slack, if connected) are now always provided. This prevents missing notifications when alert priorities are not explicitly set.
• 🐛 Deleting the last row in a field map now deletes the entire map to prevent broken behavior.
• 🐛 Fixed an issue in MS Teams tabs where severity could become unset.

Task Reminders and Due Dates

We're happy to introduce the ability to set due dates for Tasks in FireHydrant. Certain incident tasks need to be completed within a certain amount of time after the incident starts, and with reminders and due dates, you can help ensure responders complete them within the required time.

You will now see due date and time fields when creating or editing Tasks. Once set, you will, by default, receive email and Slack DM notifications and reminders:

• When assigned
• 30 minutes before due
• 10 minutes before due
• When due

Our team is happy to take feedback as we continue to improve our features—feel free to reach out to your Success Managers or Support!

Other Improvements, Fixes, and Deprecations

• 💅 We've reduced the maximum volume for alerts on Android when overriding volume settings
• 💅 Small clarifying updates were made to the warning text when attempting to Archive an incident
• 💅 When an Alert is expired and can no longer be escalated, we've added an indicator in the UI to differentiate it from other open Alerts
• 💅 Our MongoDB event source for Signals has been improved to ingest and pass along more metrics information when opening Alerts in FireHydrant
• 💅 We made additional updates and improvements to the Jira field mapping prompts we added last week to enable creating mappings for required fields more easily
• 🐛 We fixed a bug where "Medium" did not show up in selection dropdowns when setting priority on Alert Rules
• 🐛 We've addressed an issue where the wrong tab was highlighted when navigating to the field mapping tab in Jira project settings
• 🐛 The Lessons Learned tab had issues with overlapping text when the amount of content exceeded a certain threshold. This has been fixed
• 🐛 Jira ticket updates has been improved in Microsoft Teams
• 🐛 When installing Slack for Enterprise grid, we fixed an issue where users encountered a bug with setting default channels
• 🐛 We addressed an issue where notifications were posted into Slack for Milestone updates even when the setting was set to "Threaded only"
• 🐛 Deleted conditions will no longer continue to show up in the Severity Matrix - we remove them automatically
• 🐛 When creating a Follow-Up during an incident, we removed configuration error prompts for projects that are correctly configured
• 🐛 When updating members within a team, the "Last updated" time for the team was not being updated. This has been fixed
• 💥 We will be deprecating the Data Export integration and Data Export page from Analytics - all data will still be available via API, Webhooks, and other means. Please reach out to FireHydrant Support if you are actively using the Data Export capabilities today

MS Teams Summary Tab

In Microsoft Teams, we've added a Summary tab to the FireHydrant tab within incident channels. This mirrors the FireHydrant web interface, which allows you to view and generate AI summaries and AI-assisted updates using your timeline and any meeting transcripts as context.

This serves as a graphical alternative to the @FireHydrant summary command, making FireHydrant easier than ever to use!

More Jira Improvements

We've improved the Jira custom field mapping experience by allowing users to select any issue type for their tickets and then warning the user about unmapped required fields.

This is a much better, more intuitive experience and can help customers understand why their Jira ticket creations aren't working if there are missing field mappings.

In addition, you can now use custom fields as conditionals in advanced field mapping for Jira, enabling more flexibility for how you map your FireHydrant fields to Jira fields.

Android App Updates

Great news for Android users - our app updates have been approved and there are two big changes:

First, you can now create and send Alerts from your mobile application. Take the power of FireHydrant Signals with you on the go and send an alert/page to any user, escalation policy, on-call schedule, or team from your phone.

Secondly, we've updated Signals to override volume settings on Android devices. Users have sometimes had their volume turned all the way down, resulting in missed pages and alerts. Now, you can trust that you will receive an alert regardless of whether you have Do Not Disturb turned on or if your volume is all the way down.

Other Improvements and Bug Fixes

• 💅 We've limited the width of the Details column on the Signals > Alerts page so that longer alert titles don't push action buttons out of visibility within the table
• 💅 We adjusted the on-call schedules page so that schedules and their shifts would remain in line with each other instead of specific users
• 💅 The Teams page right-side drawer has been cleaned up and UI elements made consistent with the rest of our interface
• 💅 Visual updates were made to the view Change Event page to better match the rest of our platform's interface
• 🐛 We fixed a bug where "Medium" did not show up as a priority in selection dropdowns
• 🐛 Firefox users should no longer see odd CSS issues with overlapping text and clipped elements on the user interface
• 🐛 We added a retry mechanism for when API calls from Slack fail with unforeseen, intermittent errors
• 🐛 We fixed an issue where Markdown formatting wasn't being preserved when sent in custom notifications to Microsoft Teams
• 🐛 Our Terraform provider had a couple API calls for fetching services and fetching on-call schedules that didn't paginate correctly. This has been fixed
• 🐛 We corrected an issue where Datadog re-notifications for open alerts would incorrectly resolve them in FireHydrant

Notification Priorities

Responders now have the powerful capability to change how they are notified according to an inbound Alert's priority. This flexibility empowers companies to strategically interrupt their responders for the most important issues while deferring lower priority alerts to e.g., email.

Each out-of-box Transposer will have default behaviors to set an Alerts priority, but Teams can override this and explicitly set a priority on an Alert when configuring Rules.

In addition, users will now see additional settings in their Profile under Signals Notifications. The Alert Notifications are now split into three separate sections for High, Medium, and Low priorities respectively.

For example, if something is low priority, you can ask FireHydrant to just email you and you'll check in the morning. But if it's high priority, then it's worth calling you and waking you up in the middle of the night.

Documentation for Alert Rules and Notification Preferences have been updated accordingly.

Revamped Jira Onboarding

We've revamped our Jira onboarding to provide a better experience for users configuring Jira for the first time.

There are numerous small quality of life improvements, such as providing better callouts and notes for important items, refresh button for reloading Jira projects, and more!

We also allow setting a project as a default ticketing project for Follow-ups, which allows you to easily create Follow-ups from a Slack message by emoji-ing it with 📋 (or whatever you customize in Slack settings).

Finally, we added a screen for users to set up the Jira webhook to FireHydrant and to fully test two-way synchronization between the created Jira ticket and the FireHydrant incident ticket.

These changes are available now for all new customers configuring Jira for the first time. The small quality of life changes like callouts and defaults are still available when setting up new Jira projects for existing customers.

Other Improvements and Bug Fixes

• 💅 We've changed the field display from "Name" to "Incident Name" in various places like Slack, Microsoft Teams, and the web interface
• 💅 We've increased the escalation policy targets in the user interface to show up to 100 entries
• 💅 We've released a MongoDB Atlas Transposer so you can notify via Signals when an alert is raised by your Atlas database
• 💅 The Uninstall section/tab of all integrations have been revamped so that the uninstall button is clearer and differentiated from the tab
• 💅 Following some CEL processing changes under the hood, when users are building Alert Rules and attempting to match key values, we will now insert .KEY.equals(VALUE) (standard CEL) instead of .keyEquals(KEY, VALUE) (custom FireHydrant CEL)
• 💅 When users add the FireHydrant bot to a Slack channel, that channel will now populate and be selectable in dropdowns immediately throughout the application (e.g., Runbooks, Team channel selection, etc.)
• 🐛 There was a bug where dismissing the prompts for AI to fill in answers in the Retrospective would re-appear after navigating away and back. They are now dismissed for the remainder of each retro
• 🐛 We fixed a bug where users who were Viewers were still able to be assigned tasks, follow-ups, and roles on incidents
• 🐛 We addressed an issue where the duration we calculated for incident milestones could be incorrect in niche circumstances

Google Calendar Integration

We've officially released the Google Calendar integration. This new integration brings two key features: AI meeting transcription and the ability to easily schedule retrospectives.

You'll find a new integration tile for Google Calendar, and once installed, there will be a shiny, brand new Runbook step: Create Google Calendar Event. This will create an event, but more importantly, a meeting associated with this event and the ability to transcribe its audio. Just like with Zoom, this transcription will feed into your AI summary and AI-generated answers to retrospective questions and other fields. The incident and retrospective pages will also have links to the calendar event once created.

In addition, once the incident is resolved, you'll spot a new button on your Command Center page to "Schedule Retrospective." Clicking this button will take you to Google Calendar's new event page with event information pre-filled, including a link to the Incident/Retrospective and all of the incident's responders present on the guest list! Now, it's way easier to quickly schedule an incident review with all the right folks in just a couple clicks!

Lastly, once the retro has been scheduled, we will also display the date/time it was scheduled for directly in FireHydrant's interface!

Documentation can be found here:

• Google Calendar Integration
• Create Google Calendar Event Runbook Step

Liquid Variables for Labels

Labels have been present on FireHydrant's Services and Functionalities for a couple years now, but we've recently added the ability to access them via Liquid templating.

This is useful for printing out a Service's labels/details in numerous places - for Jira field mapping, to page a team with information, sending out emails, and more! You can access these values by using the following Liquid templating:

{% for service in incident.services %}
  {{ service.labels.LABEL_KEY_HERE }}
{% endfor %}

{% for functionality in incident.functionalities %}
  {{ functionality.labels.LABEL_KEY_HERE }}
{% endfor %}

Other Improvements and Bug Fixes

• 💅 Alert links are now in a separate section and limited to a maximum of five, with a link to see all alerts in the Linked Alerts tab. The overall result is a cleaner Details panel on the Command Center page
• 💅 We now support wildcard domains on allowed email senders for Signals Email sources
• 💅 If retrospective exports (e.g., Google Docs or Confluence) exist on a retrospective, we now add them as easy-access buttons at the top of the retro page
• 💅 When there are no events starred when you start a retro, we now show a prompt and link to documentation
• 💅 Retrospectives now auto-save when users navigate between tabs, ensuring that any answers to questions or contributing factors aren't lost
• 💅 We made several small UX improvements to Jira project configuration: more help text, clearer callouts to field mapping, callouts to authorize with a Service Account, field requirements so you can't choose issue types without status mappings and vice-versa, better field lengths and less crampage, and more
• 💅 In case Slack becomes unresponsive or there is a connection issue, we've implemented safeguards to prevent users from clicking "Declare" multiple times and subsequently creating multiple duplicate incidents
• 💅 The header of the Command Center now displays the time the incident was opened, which is separate from the Started milestone time which may be adjusted manually
• 💅 We now have a new transposer for Azure Monitors so you can receive alerts directly from your Microsoft Azure infrastructure
• 💅 We've renamed the "Tasks" tab to "Tasks & Follow ups" to provide better visibility to Follow-ups being contained on those tabs
• 💅 You can now delete Functionalities directly on the Functionalities page instead of going in to each Functionality's Edit page
• 💅 The Event Logs page now shows icons for each Event designating its Source
• 💅 While viewing an Event's details in the side drawer, the title and body are now Markdown-enabled to increase readability
• 💅 We clarified some wording in the modal for adding Follow-up tickets using external URLs
• 🐛 We addressed a bug where the wrong tab was highlighted in the Retrospective because the check for AI features happened after page load
• 🐛 We mended a weird issue where buttons would have scrollbars if the user's system settings were set to always show scrollbars
• 🐛 Minor responsiveness issues on the Change Events page have been addressed
• 🐛 When generating AI answers to Lessons Learned, we incorrectly showed the loading spinner on Follow-ups too even though we were only operating on Lessons Learned. This has been fixed
• 🐛 We now gracefully handle condition deletions so that if a Service is using a condition (let's say "Borked") and it's deleted for some reason, the Command Center page doesn't crash and incident updates still work
• 🐛 We fixed an issue with Email Sources where we were using case-sensitive encoding of IDs when all email clients tend down-case email addresses. This is now case-insensitive
• 🐛 We mitigated a bug where switching from Incidents and Impacts to MTTX Analytics analytics subpages broke and reset the filtering
• 🐛 There was an issue where pairing "Declared after" with "Assigned Teams" or "Impacted Teams" filters on the Incidents page returned nothing that has been fixed
• 🐛 We fixed a bug where invalid dates in filters would break the whole page. Now, the filter won't save if values are invalid
• 🐛 We addressed a bug where custom working hours weren't respected or used when calculating and inserting shifts in on-call schedules
• 🐛 We corrected a problem where Jira tickets created from Alert Routing were either overwritten by a Runbook step also creating an incident ticket, or there would be duplicate incident tickets on the incident
• 🐛 Incident search would produce inconsistent results when the incident name included numbers. This has been adjusted so that when searching numbers, we would not only find incidents whose number matched, but also incidents whose titles include said numbers

Email Event Source

We're excited to introduce Email Event Sources! This came as a popular feature request, especially from customers using some legacy systems without webhook capabilities.

You can now configure Email sources in FireHydrant to receive emails that trigger alerts, with customizability such as allow-listed senders and Trigger Rules. You can find more information in the documentation here.

Saved Views for Alerts

Building on our existing infrastructure, we've added Saved Views to our Alerts page! Pre-configure filters so you can see your alerts by Rules, Teams, Users, and more!

If individual users want to quickly see only Alerts belonging to them or to their Team/Service, they can configure that as a default view.

Other Improvements and Bug Fixes

• 💅 You can now reorder component groups in FireHydrant status pages
• 💅 We've added the ability to bulk edit Tasks and Follow-ups in the web interface
• 💅 When adding existing Jira Cloud tickets as external tickets, we will automatically insert the ticket's summary as part of the link's description so users have more information aside from the ticket's number
• 💅 Whenever an incident field changes, we now display the original value in the timeline next to the new value
• 💅 We've added the Linked Alerts tab to the Microsoft Teams FireHydrant tab shown in incident channels
• 💅 You can now set a default Microsoft Teams channel for team alerts. Things like coverage requests, shift overrides, and other notifications will post here automatically for the team
• 💅 We noticed we were using the same icon for both Signals alerts as well as internal status pages for each incident. We've changed the icon we use for internal status pages
• 💅 We updated our Functionalities create/edit page to use the new styling that's consistent across the rest of the application UI
• 💅 New users of the Microsoft Teams bot will receive a welcome message with links to documentation and other instructions
• 💅 We've added a new column on the Runbooks page for Categories, which are collected based on the steps used within the Runbook
• 💅 We've updated our scoring system for related incident searches - the AI copilot should now be providing even more accurate suggestions for related incidents
• 🐛 We fixed an issue where canceling an additional edit to a Contributing Factor after a previous edit would suddenly hide the value
• 🐛 We fixed a bug in Slack where Alerts were updated but the timestamps remained the same and still showed the original creation time
• 🐛 There was an issue with trying to open the dropdowns after editing multiple Milestone times on an incident which was addressed
• 🐛 Responsiveness issues with the FireHydrant tab in Microsoft Teams were fixed
• 🐛 We resolved a bug where our Change Events page wouldn't load for long periods of time, and after that loading period, the page would be empty even though Change Events existed
• 🐛 We've fixed a problem with retrying actions in Slack while also avoiding hitting Slack's rate limits for large queues of updates
• 🐛 Some minor alignment and spacing issues were corrected for custom time windows when configuring on-call schedules
• 🐛 We addressed an issue where trying to set a label with an empty key on a service catalog component would break the page instead of gracefully handling the error

Linear Integration

We're excited to announce our new Linear integration! They've built an exciting product for project management and it's been popularly requested from us as an integration.

With the Linear integration, you can create incident tickets via a Runbook step as well as create follow-up tickets in any Team/project of your choice!

Linear, like our other ticketing integrations, is bi-directional - changes in status of the FireHydrant incident or Follow-up will automatically change the linked ticket's status in Linear and vice-versa.

Any Follow-up Linear tickets will automatically be set as sub-issues of the Incident ticket.

To learn more about the Linear integration, check out the documentation

Customize Handoff Reminders

Previously, the default behavior was to notify users 24 hours before the start/end of a shift and then immediately when the shift begins/ends.

Now, you have the ability to customize this in your user settings. On top of changing the time frames of when you are notified about upcoming/ending shifts, you can also choose where you'd like to be notified (Slack vs. email). Take a look at your Profile page and check it out!

Oodles of Quality of Life Improvements

We've added numerous quality of life improvements for various different tasks within FireHydrant:

• You can now sort the Incidents page by Date Created, Severity, and Priority. You'll find the "Sort by" dropdown on the Incidents page just below "+ Add Filter." More parameters for sorting, including duration of incident, are still in-progress
• We've added additional filters to the Settings > Users page to filter users by their (access) roles, whether they have private incident access, and their status (enabled/disabled). These new filters join our existing filters to show users with and without notifications configured
• On the Signals > Alerts page, you can now bulk resolve alerts. You'll see checkboxes available on the page so you can check all alerts or some alerts and then a bulk actions dropdown will show
• In line with our other re-ordering capabilities, you can now reorder your Priorities. Any changes in this ordering will be respected everywhere you may see the priority dropdown
• We've added the ability for you to search incidents according to roles existing on the incident and who was assigned to said role. Can't remember that one incident where Jimothy was the Commander? Now you don't have to - just filter on Jimothy = Commander using our filter dropdowns

We hope to continue cranking away on little things that make FireHydrant easier and better to use!

Other Improvements and Bug Fixes

• 💅 We've added Incident Impacted Infrastructure as a selectable condition in Jira custom field mapping. Now, you can map different fields to Jira based on which of your Services and components are impacted in FireHydrant
• 💅 For Jira Server (On-Premise), we've added the capability to map custom fields that are linked to Jira Assets - some customers are using Jira Assets as a Service Catalog so mapping these fields on tickets helps streamline their analytics and automation
• 💅 When declaring an incident and updating impacted components, we will make severity recommendations if the selected component has an entry in your severity matrix. This will work in Slack, MS Teams, and the web interface
• 💅 You now have the ability to upload different types of files to the FireHydrant timeline, including PDFs, Microsoft Word, Excel, and Powerpoint files, RTF, CSV, and ZIP files
• 💅 We've added international Voice support for Greece (+30). Remember to download the updated virtual contact card here.
• 💅 On the Incidents and Impact page, we've adjusted the Incidents by Severity chart to display the severities in order of severity. Previously they were inconsistent
• 💅 Non-licensed Microsoft Teams users will now be able to execute basic commands like seeing who's on call, service information, and of course, declaring incidents. Owners and Members will need to first set an API token for the bot to assume for non-authenticated users. Browse the documentation here
• 💅 Our Microsoft Teams integration now restricts Viewers from performing any actions other than viewing incidents and information like services and who's on call, similar to unlicensed users
• 💅 Previously, we only had a Runbook step for creating incident Jira tickets and Follow-ups were created manually, but we received feedback that there were consistent Jira tickets users wanted to create each time (e.g., a separate ticket to track RCA completion). So there's now a new Runbook step "Create a Follow-up Jira Cloud issue" to meet your needs
• 💅 We've added our Status update templates as Terraform resources so you can now manage your templated status messages as code
• 🐛 We fixed an issue where Jira Alert Routing was unintentionally changing the original ticket's type or creating additional tickets after an incident is started
• 🐛 We fixed a bug where tagged user group handles weren't replicating properly into the FireHydrant timeline's messages
• 🐛 There was a bug where messages mentioning users in Slack were showing up as numbers instead of their names in the FireHydrant timeline. This has been addressed
• 🐛 After adding a Functionality with responding teams to an incident, users were still receiving suggested resource messages in Slack even if these types of notifications were silenced. This has been fixed
• 🐛 We addressed some typos and mis-formatted documentation in our Terraform docs for Signals Escalation Policies
• 🐛 We fixed an issue where automatically adding teams whose services were impacted on incidents didn't work if the team only had one user
• 🐛 There was an issue where existing related incidents were removed when attempting to add more related incidents to an ongoing one which has been fixed
• 🐛 We addressed a bug where changing the phone number while it was added but unverified would not update to the new number and instead ping the old one

Tutorial Runbooks

Capitalizing on the flexibility of FireHydrant's Runbooks, you can now define your own Tutorial Runbooks (or start from a template and customize) for your responders to refer to whenever needed.

Once configured, check the setting for "Use for tutorial incidents" and it will automatically execute whenever users run /fh tutorial command in Slack or @FireHydrant tutorial in Microsoft Teams.

This also prevents it from accidentally attaching to real incidents, and you can update the Runbook as needed for whenever your processes change.

Visual Runbook Explorer

We've introduced a tree view for Runbooks. When configuring Runbooks or viewing a Runbook's execution in the Command Center, there is now a switch present with the "Explorer" label. Toggling this changes the view to the visual tree. You can also add and edit steps from within the explorer pane as well.

For people who are more visually-inclined, now it's easier to see how steps may depend on each other for completion and what executes immediately after incident trigger.

Automatically Rerun State Transition Steps

Rounding out our improvements to state transitions in Runbooks, any steps with state transitions as conditions now have an additional checkbox to "Rerun on every transition (Optional)". You can use the automatic step rerunning with the Attach A Runbook step to automatically re-attach runbooks on state transition.

Please note that not all steps support rerunning! Runbook steps that previously supported repeating are supported here, as well as a couple additional ones like renaming your Slack channel and attaching a Runbook.

Runbook steps traditionally could only be rescheduled every five minutes at the shortest, but this option enables steps to fire immediately upon transition. So now, you'll be able to do things like:

• Send an email out every time the Milestone changes
• Notify a Slack channel if the Severity upgrades or downgrades
• Send a webhook to your logging tool that the incident changed Severity

We hope this capability helps satisfy our customers' needs around ensuring updates are sent to custom locations in a timely manner!

Datadog Service Import

You can now import Service Catalog components from Datadog! To get started, you'll need to update the Datadog integration settings in FireHydrant with API and Application keys. Once done, head over to Catalog > Import from third party, and you'll see Datadog as an option.

Depending on how many services you have, it may take several seconds to load all of them. From there, you can decide whether to link them to existing components or to create new ones!

Other Improvements and Bug Fixes

• 💅 We've added a displayName filter to our /scim/v2/groups endpoint for SCIM, allowing scripts and automation to filter down the fetched list of teams by a team name
• 💅 In Microsoft Teams, different users may be logged in to different FireHydrant organizations. We've shipped a change that prevents users logged into one organization from interacting with cards created for a different organization
• 💅 We've added transposers for Chronosphere and GCP Service Health, allowing you to ingest Events from these sources out-of-box for alerting in FireHydrant
• 💅 The On-Call Schedules page for a team will now always show on-call schedules in the order that they were created, ensuring consistency each time someone looks at the calendar
• 💅 We now support reordering conditions in the user interface. Reordering these will impact the order they are shown everywhere else across the platform, such as when marking a Service as impacted in Command Center or in chat apps like Slack or Microsoft Teams. This change also will prompt users to modify their severity in the web ui if they have a configured severity matrix.
• 💅 Customers have requested an additional Tier 0 for Services and Functionalities so we've added it to the list of available values
• 💅 The "Attach a Runbook" step can now be re-run on every transition, in line with the state change capabilities
• 💅 For Jira On-Prem/Server, Custom Fields based on Jira Assets are now mappable in custom field mapping
• 🐛 We fixed a bug where our AI Copilot was suggesting the same incidents multiple times. Now, if an incident has been suggested before, it won't be suggested again during an incident
• 🐛 There was an issue where default Jira issue types weren't selectable in Jira project configuration even after mapping custom required fields. This has been fixed
• 🐛 We fixed an issue in Microsoft Teams where a templatized notification message would not update with latest status and links until after an update was made on the incident
• 🐛 We fixed a bug where extremely long idempotency keys on inbound Events would throw an error and not ingest the Event at all
• 🐛 There was an inconsistency in behavior when users were attempting to search for incidents that contained numbers in the title which was addressed
• 🐛 Our Grafana transposer was not correctly copying over parameters to Signals annotations so we've fixed this
• 🐛 We had been expiring Alerts that exhausted all Escalation Policy steps and handoffs even if they hadn't reached the 24-hour open threshold. This has been fixed
• 🐛 Users were getting Liquid errors on valid templating. It turns out this is due to implementation differences between Ruby Liquid (what we use) vs. Javascript and other implementations. In our Liquid previews, we now display descriptive error messages and suggestions for workarounds for specific issues
• 🐛 We fixed an intermittent issue with the Notify Slack Incident Channel w/ Custom Message where the Action Button field was sometimes required and sometimes not. This is now consistently optional
• 💥 We've disabled the ability for an Escalation Policy to hand off to itself. This prevents an escalation path from running until the end of time, since your on-call responders won't live that long. Instead, we recommend using Repeats to rerun the Escalation Policy (a reasonable number of times).

For years, FireHydrant had a Microsoft Teams bot that could do a few basic things like notifying channels. But users were clear in their feedback: they wanted all of the capabilities of incident management without leaving Teams.

After many quarters improving other parts of our platform, we're excited to unveil a brand new Microsoft Teams bot - this time, with full IM capabilities.

Getting Started

We've gone over the full list of new functionalities in our beta release blog post. You can read the blog post here to get an overview of what the MS Teams bot is capable of, with much more coming prior to GA and after.

To get started, schedule a demo or reach out to your Customer Success representative. Once we've spoken with you and your team, we can enable you on the Microsoft Teams beta and you'll be able to install the integration.

Once enabled, you will find a new tile called "Microsoft Teams (beta)" on your Integrations page.

From there, browse our documentation linked below and reach out to our team if you need help, support, or to provide feedback!

• Installation Docs
• MS Teams Responder Guide
• Full List of MS Teams Actions and Commands
• MS Teams Runbook Steps

Rerun Any Runbook Step

Following up last week's Runbook improvements, this week we're enabling the capability to rerun any Runbook step (not just failed or repeating ones!) for all users.

Steps that can be executed multiple times (e.g., notifying chat channels, email steps, incident update steps, and more) will now present a "Run step again" button that you can execute at any time ad-hoc.

Note that this button will not be present for steps that are single-execution only (e.g., creating an incident channel, assigning a team, etc.). Those will only present "Rerun" buttons if they have failed to execute.

Milestone and Severity Movements Up or Down

Also hot on the tail of last week's Runbook conditions improvements, we've added some additional pieces for Milestones and Severities.

Severities now have explicit conditions for "escalates" and "de-escalates", allowing you to automate Runbook steps based on the severity going up or down. We've also added "moves forward" and "moves backward" conditions for Milestone changes, allowing you to automate based on an incident progressing or regressing in progress towards resolution.

Reorder Your Severities

Severities can now be reordered - instead of having to go through and rename the existing order to what you want, you can simply move severities up and down in the order you desire.

Reordering these will affect the order they are displayed to users on all interfaces, from the web UI, to your chat bot's declaration screen, and more.

Other Fixes and Improvements

• 💅 The Runbooks conditions were revamped and are now visually cleaner and allow for searching!
• 💅 We've introduced a Transposer for Pingdom, allowing FireHydrant to support ingesting Events from Pingdom out-of-box for alerting with FireHydrant Signals
• 💅 Custom fields are now also included when exporting a CSV of incidents on the Incidents page
• 💅 We've added a link to Jira field mapping documentation on the Jira project configuration page to better help users understand why they may not be seeing issue types selectable for incidents or follow-ups
• 🐛 We fixed a bug where opening a Runbook in a new tab would close that tab immediately
• 🐛 The "Action button" field for "Notify Slack incident channel with custom message" step should be optional, but users who hadn't updated the step since we introduced that field were running into problems saving changes. This has been fixed
• 🐛 Several typos in the Slack bot help command were corrected
• 🐛 We fixed an issue where (re-)authorizing Slack would overwrite existing Slack steps in Runbooks
• 💥 We've removed the in-app notifications (the little bell icon + dropdown at the top). It was limited in functionality, saw low interaction, and provided little value for our users, so we've opted to remove it

On-Call Slack Groups

FireHydrant is excited to introduce Slack group syncing for on-call schedules! You can now point one or more on-call schedules at the same Slack user group and we’ll sync all of their on call users to that group. This makes it easy to sync all of a team’s schedules to a single Slack handle for the whole team.

To start using this feature, you need to first re-authorize your Slack integration as it requests additional scopes to modify Slack groups. You will also need to give the FireHydrant bot permission to manage user groups in your Slack workspace settings. Next, ensure there is a Slack group FireHydrant can start syncing with (e.g., "@database-oncall"). Then, go to your Team's page > On-Call Schedules and click the ellipses next to any schedule you'd like to start syncing with a Slack group handle!

Stop and Rerun Runbooks

We've added the ability to Stop and Rerun Runbook executions. Stopping a Runbook will immediately cease all of its steps and ask for a cancellation reason. Once provided, this logs an event in the timeline.

Rerunning a Runbook will stop/cancel any pending steps, and then re-execute all steps within the Runbook. No setup is necessary to use these features.

On Any Severity or Milestone Change Runbook Conditions

With Runbooks, FireHydrant users never had to understand the difference between "triggers" and "conditionals" - if an incident was e.g. SEV3, then the SEV3 Runbook would attach and execute. This allowed for powerful, flexible layering capabilities while keeping them easy to understand.

But of course, this led to a quirk - you had to specify explicit conditions, which in turn meant you had to know what a value (e.g., Severity) would change to. This doesn't work for workflows like "Send an email when the severity changes."

With feedback from customers, we've started adding "On Any Change" conditions to our Runbooks, starting with Severity and Milestones. You can find additional options in those conditions for "changes."

Other Fixes and Improvements

• 💅 We added a firehydrant_ingest_url data source in Terraform to fetch targeted webhooks for specific teams, users, and more. Docs here
• 💅 In the milestones section of the Retrospective, we previously hid any milestones that did not have a timestamp. Now, we show them and add an action button to add a timestamp, making it easier to see which milestones are missing data
• 💅 Incident types can now be specified in the Signals Terraform. Docs here
• 💅 We've officially exposed the /v1/metrics/mttx API endpoint so users can fetch the same data that we show on the MTTX Analytics page. We highly encourage users to switch to using this endpoint over the other metrics endpoints
• 💅 We've added tags and customer_impact_summary as additional fields in the incident CSV export
• 💅 The Signals migration tool will now also create FireHydrant user blocks in the generated Terraform. This is highly useful for net-new customers migrating from other alerting providers to FireHydrant and have not yet configured their SSO
• 💅 We've exposed the position parameter for Severities API, allowing users to now re-order their Severities. This will impact the order everywhere Severities are selectable
• 💅 We've added a Finland phone number to our pool of international voice callers. Remember to download and add the updated vCard!
• 🐛 We fixed an issue where if a monitoring tool sent us an Event saying an existing FireHydrant alert has been resolved, we wouldn't mark the Alert as resolved if it had already been acknowledged
• 🐛 When creating a Runbook from a suggested template, there was an issue with empty default values that prevented users from editing certain steps. This has been fixed

Alerting Migration Tool

We've released and open-sourced an application to import your Users, Teams, and/or Services from existing alerting providers to FireHydrant's Signals platform!

After picking which elements to import, we will generate a Terraform file for you which you can tf apply or you can combine it with your existing Terraform configurations.

To learn more, visit the blog post.

Summary Backfill, Suggested Incidents, and Auto-Generation

We've been hard at work teaching our AI copilot how to be more useful to incident responders, and now it's got a variety of new capabilities!

First, we ran a backfill on all historical incidents on our system - every incident (unless you disabled AI) now has a summary generated for it and is available to anyone who visits the incident in the UI or the Slack channel, if it still exists.

You may have noticed a sneaky addition to the Command Center, but a couple weeks ago, we added a "Suggested Incidents" section to the Details panel, which automatically populates based on what the AI copilot thinks are the most relevant incidents. These suggestions will now also be posted into the Slack channel (along with a snooze button if you don't need 'em anymore). This individual feature can be turned on/off in Settings > AI > Related Incidents (requires Owner permissions).

The copilot compares a variety of factors, including incident status updates, chat messages, roles and teams assigned, and more. If you have thoughts or comments, keep delivering the feedback so we can continue to refine!

Other Fixes and Improvements

• 💅 We revamped the Jira integration settings project table. Now you'll see in the table whether incident tickets and follow-ups have been configured for each project
• 💅 We also revamped the connection health styling in your integrations, so all warnings or other messages are organized neatly in a table now, improving legibility
• 💅 You can now filter and search for specific values on single-select and multi-select dropdown questions in Lessons Learned
• 🐛 We fixed an issue that was causing only the first two members of a team when choosing a team to assign to an incident in Slack. We now properly show the entire team and all of their roles, if role assignments exist.
• 🐛 The conditions dropdown menu in Jira field mapping was previously cut off in the side drawer and this has been fixed
• 🐛 We fixed an issue where some users with Collaborator permissions were unable to send Signals alerts. This has been fixed so all Signals users can now send alerts.
• 🐛 There was an issue where users couldn't change a custom field mid-incident if it was required at declaration. This has been addressed and custom fields should be editable, they just cannot be cleared if they're a required field
• 🐛 We fixed a minor misalignment of the Signals icon on the Incidents list page

AI Summary Variable

The latest incident AI summary is now accessible via a Liquid variable {{ incident.ai_incident_summary }}. This means the latest summary, including all the context provided from timeline and Zoom transcript, can be sent anywhere such as other channels, emails, internal status pages, and more.

Let FireHydrant's copilot update your boss so you can focus on the incident!

Raised Custom Field Limits

Currently, multiple organizations within individual accounts share the same global limit for Custom Fields which we set at ten for historical reasons.

We've now raised the custom field limit from ten to twenty for enterprise accounts. We hope this makes it easier for you to track your custom data across all of your organizations!

User Notifications Filters

The Users page now allows you to filter users according to which notification methods they've set up. This helps you more easily ensure users don't forget to configure ways to page them

Other Fixes and Improvements

• 💅 We now send a Webhook event whenever users make any edits to milestones' timestamps
• 💅 Inbound alerts that match idempotency keys with an existing, open alert within the last 24 hours will now no longer create new alerts. If an existing alert with matching key is dismissed or resolved, or if it's been longer than 24 hours, then a new alert will be opened
• 🐛 We fixed the "Configure integration" link to actually look like a link on Runbook steps whose integrations haven't been configured
• 🐛 We fixed a bug where users were unable to subscribe to FireHydrant status pages due to a TLS certificate error
• 🐛 We fixed a bug with how we handled the indices of alerts that had reached a terminal state, resulting in weird ordering in the alert's timeline
• 🐛 We fixed an issue where the Jira Runbook step wouldn't correctly assign the Jira ticket if the Runbook was attached manually
• 🐛 We fixed a minor glitch where clicking on the "Generate" or "Regenerate" button in the Command Center would also collapse the accordion it was on
• 🐛 We fixed a bug where hitting 'Enter' when searching for Runbook steps, even if there were matches, would result in an exception
• 🐛 We fixed an issue where users with the maximum number of custom fields would encounter an error when trying to edit an existing custom field

To follow up last Friday's cool new Zoom features, we've got a plethora of other improvements and fixes that our team cranked out last week!

Granular AI Controls

When FireHydrant first put out our AI copilot feature, it was an-all-or-nothing setting that was enabled for all features for your organization.

Now, we give you greater granularity so that you can turn AI on or off for specific features. Want smart summaries when people join, but prefer incident responders write manual updates? No problem!

The singular toggle switch on the AI settings page has been replaced with a bigger menu of individual line items.

Webhooks for Escalation Policies, On-Call Schedules, and Users

Many of our customers migrate to Signals with existing monitoring tools. While we offer Alert Triggers and Rules to route inbound events, oftentimes customers already have routing configured in their monitoring and don't want to reconfigure all of this in FireHydrant.

A few weeks ago, FireHydrant released team-targeted webhooks so that you can directly target a team's default escalation policy. Now, we've extended the flexibility to allow directly tareting Escalation Policies, On-Call Schedules, and Users.

Simply head to the Alert Triggers tab in your Team's settings to find the dropdown for specific targets and copy your webhooks.

Preemptive Shift Overrides

FireHydrant has built Signals with ease of use in mind - we've made it extremely simple for users to request coverage from other team members. But what if someone else already knows what times they need to step in?

Now, users can override partial or entire shiftswithout the original shift owner needing to request coverage. You'll find buttons to do this when clicking on the shifts in the calendar view!

Other Fixes and Improvements

• 💅 When paging with Signals from Slack or in the user interface, the Description for the alert is now optional instead of mandatory
• 💅 When an Alert is posted to Slack, we will no longer truncate the alert summary or description
• 💅 Event Sources for Signals and Team-based webhooks are now restricted to only users with Member permissions and above
• 💅 You can now export the list of users to CSV on the Users page in your Organization settings
• 💅 Alerts sent via email previously only included the title but will now include the title and full description of the alert
• 💅 You can now cancel your coverage requests from both the mobile app and the web interface
• 💅 If an Event Source sends a recovery alert to FireHydrant after sending an initial alert, FireHydrant will now resolve that initial alert
• 💅 We had previously been calling from a US number with 619 area code regardless of the recipient's country. This resulted in calls not going through, or the receiver being charged for international phone rates. We now will attempt to match a local number and fallback to a US/Toll-Free number if unavailable. For our voice coverage, visit our docs
• 🐛 We fixed a small visual glitch where the Liquid templating preview button's row slightly overlapped the input textbox above it and covering the border
• 🐛 We fixed a bug on the Task Lists page where attempting to add a task list resulted in a blank page
• 🐛 We fixed an issue in Slack where longer descriptions for severities were truncated. The full description now displays below the severity dropdown
• 🐛 When querying alerts by service, the API was only returning open alerts instead of all alerts. This has been fixed so that all alerts for a service are returned regardless of status
• 🐛 We fixed an issue where if a Runbook step used both "Current milestone is" and "Time since milestone" conditions, it ignored the time-based condition
• 🐛 We fixed a small visual blip on FireHydrant status pages where "All Systems Operational" erroneously showed a small empty pill
• 🐛 We fixed a bug where assigning an on-call schedule from PagerDuty to a role within Team settings resulted in a misaligned table
• 🐛 We fixed a small issue where if the "Create/rename Slack channel" step executed after the incident was resolved, it would show as failed even though it worked as expected

We know a lot of our users are often on Zoom bridges triaging and mitigating their incidents. But where does all of that context go once you click “Leave Meeting”?

Not to fear - FireHydrant's newest Zoom features are here. This week, we are stoked (fireplace joke) our Zoom app changes were finally approved and our looming improvements have whooshed through the gloom to bring some bloom to your incident rooms.

Two new settings have been added to your Create a Zoom Meeting Runbook step: Transcribe Meeting and Automatically attach links to cloud recordings.

How does it work?

With the transcription setting enabled, FireHydrant will invite an "incident scribe" to join your call as a fly on the wall, punching figurative keys as your incident stenographer. Don't worry - we've trained our bot to not be judgmental.

That transcript is then coded live and available to access via the incident's Command Center. All you need to do is refresh the page to get the latest transcript!

Supercharged summarization

Transcripts are not only recorded into your incident - they will also be used as context for any AI-assisted prompt generation.

So, even if your responders have been busy and neglected to post updates to Slack or the incident timeline, FireHydrant will still have context from their conversation on Zoom to generate rich summaries and information for different fields. This includes summaries, customer impact, updates, any retrospective questions, and more!

Anyone joining the Slack channel or viewing the incident in FireHydrant UI won't have to join the Zoom meeting to ask "WhAt'S gOiNg On?" anymore, even if responders haven't been posting updates and changing milestones! (Tsk tsk, though)

Chat too? Yep.

BUT WAIT, THERE'S MORE! Now, any chat messages posted into your Zoom chat will also now be replicated to your incident timeline just as if they were coming from slack or our in-app chat system.

This truly tears down the wall between your meeting bridge and incident home, making Zoom a true extension of your FireHydrant incidents.

Easily access Zoom recording links

With the recording link option enabled, once the meeting bridge ends, FireHydrant will wait for Zoom's confirmation that it's done processing the recording and automatically attach the recording link to the incident.

No more reaching out to your admin or whoever started the Zoom to awkwardly fetch the recording link (again)!

End Linked Meetings

We announced this a couple weeks ago, but to wrap up the Zoom recording link changes with a bow, we released a new Runbook step to preemptively end your linked Zoom bridges so that they stop recording and start processing sooner!

This is important, as sometimes when there are no hosts on the meeting bridge, everyone may leave but the meeting may not necessarily terminate. This Runbook step ensures the termination happens and automates it.

Get Started

To try out your new incident scribe:

1. First, have an Owner in your FireHydrant organization head to your Zoom settings and reauthorize the Zoom app since FireHydrant must request additional scopes for these new features (part of why we'd been in review w/ Zoom since February...)
2. Then, head to your Runbooks and modify (or add) a Zoom step that creates an incident conference bridge. You’ll see the new dropdowns for transcription and recording links.

Thoughts, questions, or feedback? Reach out to our team any time!

Auto-Alerting FireHydrant Teams on Signals

When marking Catalog services or functionalities impacted on an incident, FireHydrant had long supported paging linked Escalation Policies and schedules from external alerting providers like PagerDuty and Opsgenie. Today, this feature is now available for FireHydrant's alerting platform, Signals.

To use this feature, ensure your services and functionalities have this setting checked and that the responding teams have default escalation policies.

View Shifts, Request Coverage in Mobile App

The FireHydrant mobile application now offers the ability to view all of your on-call shifts, request coverage for them, and view open shifts! Take the convenience of FireHydrant's scheduling flexibility with you on-the-go.

Learn more about how FireHydrant approaches schedules and shifts in our documentation here.

Cloudflare Transposer

We've added a transposer for Cloudflare. The text from the alert will be inserted as the description of the inbound Event to FireHydrant. Now, you can page via Signals from any events sent from Cloudflare!

Other Fixes and Improvements

• 💅 Signals alerts associated with an incident will now auto-resolve with the Resolve Linked Alerts Runbook step
• 💅 Previously when an incident was resolved, we stopped posting Task List notifications to the incident Slack channel or directly notifying the user with the bot. Now we will continue to notify the user and post this type of update even after resolution, if not silenced in Slack settings
• 💅 In Signals Escalation Policies, we will now automatically escalate to the next step if a particular step in the policy is notifying schedules that are all set to "off-hours"
• 💅 We've improved error reporting for the Webhook Runbook step so that users can better understand why the step fails
• 💅 Last week, we added the ability to filter alerts in the UI by various attributes like services, users, etc. We've extended this capability to the FireHydrant mobile app and you can now filter alerts by status, team, and if they are assigned to you
• 💅 Previously, you could only configure daily or weekly schedules via Terraform. We've updated the Terraform provider for Signals to support the "custom" scheduling strategy. Browse the Terraform docs here
• 🐛 We fixed an overflow and display issue with the Runbook webhook step
• 🐛 Previously, running /fh summary may fail when an AI summary had not yet been generated. We now present you a button to manually initiate the summary generation, if desired
• 🐛 We fixed an issue in the UI where a saved view and a new view duplicated from it would both show as active. Saved views are now uniquely differentiated, even if their filters are the same
• 🐛 When running /fh page in Slack, we fixed erroneously showing that the Description field was optional when it wasn't
• 🐛 When declaring an incident from a Signals Alert in the UI, we fixed an issue where clicking "Create incident" failed with a Milestones error
• 🐛 We fixed a text wrapping issue for Severities and Priorities having their descriptions truncated when declaring an incident from Slack.
• 🐛 We fixed a bug in Jira field mapping where if you selected Current Severity or Current Priority as the value, we passed in the entire object body instead of the expected slug as a string. Now, it should just map the expected slug as a string (e.g., SEV1)
• 🐛 Some Runbook steps were incorrectly handled in field validation and showing as required even when they were not. Fields should be either not required anymore, or will be marked as required accordingly
• 🐛 We fixed a UI Timeline issue where the leftmost column was squashed if the content was lengthy for Follow-Up updates

Alert Filtering

Alerts in the user interface can now be filtered according to various facets such as impacted Service, Functionality, or Environment, Teams, matched Rule, and more!

This makes it much easier to trace how Alerts make it into your system and which components they align with.

Other Fixes and Improvements

• 💅 Tags can now be included in the Signals alert webhook body, and they can be used to tag related Services, Environments, and Functionalities. Find more information in our Events Data model here
• 💅 We have added a new Runbook step for End Linked Zoom Meetings. For all Zoom meetings linked to the incident, you can proactively automate terminating them so that recordings can be processed immediately
• 💅 We have added Liquid previews and snippets for custom values when configuring Jira field mapping
• 💅 When someone on your team claims a shift coverage request, we now post into the team Slack channel or DM the coverage requester in Slack if a team Slack channel doesn't exist
• 💅 We've added connection health checks for Opsgenie integration. You should now see a "Connection health" section in your Opsgenie settings
• 🐛 Fixed an overflow issue where the conditions dropdown in Runbooks was cut off in the modal
• 🐛 Fixed an issue where Signals was counting against the number of integrations in accounts
• 🐛 Fixed an issue in Runbooks where field validation was triggering after clicking away from any field. We now trigger field validation when users try to click "Add Step" and there are required fields not filled out
• 🐛 Fixed an issue where Create or Rename Slack incident channel Runbook step could not be saved due to empty Communications field
• 🐛 Fixed a bug where multi-select fields in the FireHydrant UI were not validating correctly

Signals Webhooks in Beta

We love that our customers are finding value in Signals and want to continue expanding on custom workflows. So we released Signals Webhooks in beta - building on our existing Webhooks functionality, FireHydrant can now send Webhooks to external destinations on any Signals/Alert action. Find the documentation here.

Liquid in Status Templates

FireHydrant now supports using Liquid templating when configuring Status Templates. Templates with dynamic incident data help reduce the cognitive load for your responders so they can quickly post updates and immediately return to the issue at hand.

Dynatrace Event Source

FireHydrant now supports Dynatrace as an event source for Signals alerts. You can find it in the table on the Event Sources page. Click View on the right-most column of the table to see an example payload and how FireHydrant translates it into an event.

Other Fixes and Improvements

• 💅 We've officially added SMS support for India and SMS + Voice support for Poland. The numbers for each have also been added to the vCard
• 💅 You can now select FireHydrant Escalation Policies as targets when using the Assign a Role Runbook step.
• 💅 We now show a more helpful error message when assigning a team fails in Slack
• 💅 We removed the checkbox for Internal Status Page when running /fh update from Slack, and all updates posted to the incident will always post to Internal Status Pages
• 💅 We made performance improvements to the login page and reduced the time to First Contentful Paint (FCP) and Largest Contentful Paint (LCP) by 66%. We also reduced the total blocking time from 10ms to 0ms
• 💅 We adjusted the responsiveness of components in our web application, particularly around the ~1300px width
• 💅 FireHydrant status pages received updates to some light mode styling and timestamps now all show in the user's local timezone, showing both UTC and local times when hovered over
• 💅 FireHydrant status pages also now show ongoing incidents' current milestones as well as severities and priorities at the top of the main status page
• 💅 We updated the names of several Runbook steps, namely Microsoft Teams and Slack steps, to be more explicit
• 💅 We now support creating private Runbooks from our Terraform provider
• 🐛 Fixed a bug where searching and filtering wasn’t working when attempting to link external PagerDuty services to FireHydrant components in Catalog
• 🐛 Fixed an issue where users will still seeing error messages in Jira about our legacy capability to link Jira tickets to Tasks
• 🐛 Fixed an issue where the original authorized user couldn’t re-authorize the Jira integration
• 🐛 Fixed an issue where only the first of multiple linked external Jira incident tickets were updated when the incident was updated
• 🐛 Fixed an issue where users could inadvertently click “Declare” multiple times in Slack when there is a connectivity issue, resulting in duplicate incidents declared
• 🐛 Fixed unclear documentation in API docs for metrics and regenerated the Go client
• 🐛 Fixed an issue in Slack where /fh private was still using a deprecated modal. It now is aliased to /fh restrict and both will open the same, new modal
• 🐛 Fixed an issue/inconsistency in Slack where some users were tagged and added to the channel while others were not when assigned tasks or roles

Getting Started is Easier

Runbooks are the core of an automated incident management process, and now, it’s even easier to get started with them in FireHydrant. Choose from several example runbooks for common incident scenarios. Additionally, when creating a new runbook from Scratch, FireHydrant will suggest several steps for you to add based on the integrations that you’ve already installed. Check out the updated experience by creating a new runbook today.

Navigating Steps is Easier

Not only is it easier to get started with Runbooks, but we’ve also revamped how you search and add step types. Now, steps can be listed out by either integration or category, allowing you to figure out which step makes the most sense for your process. Additionally, we’re now showing the configuration status for any integration steps that you might want to include. Don’t have an integration configured? Just click through to quickly set it up and get right back to your runbook.

Editing is Easier

Editing runbooks also got a lot easier with our latest release. When you navigate to a runbook now, you are dropped automatically into edit mode so that you can make quick changes and be on your way. Additionally, step-editing got even easier with a new two-step modal that allows you to configure the step and then set the conditions for running the step. Check it out today by clicking into any of your runbooks or creating a new one!

Custom Fields in Analytics

After launching MTTX analytics, we’ve overwhelmingly heard that custom fields do not just belong in filters, but also as distinct groups of incidents to be analyzed. We’re excited to tell you that you can now group by a particular custom field in MTTX analytics, allowing you to group incidents and their data into custom field driven aggregates directly in MTTX analytics. Try this out by navigating to MTTX Analytics and selecting “Grouped By” and selecting a custom field that you have on a significant number of incidents.

Better Slack Update Messages

Slack channels during an incident can be a noisy place. Updates from responders and system messages from FireHydrant can get all tangled up and confusing. So we recently updated some of our Slack messages to be simpler and to-the-point, making it even easier to understand what has changed about an incident. Check out the changes the next time you create or update a task, follow-up, and role assignment. Also any edit to the incident details will be much easier to digest!

Update Across Status Pages in Command Center

When using FireHydrant in Slack, users are able to easily update milestones and post a status update across all of their status pages. However, in the command center, this ended up being a multi-step process with milestones changes and updates being atomic for each status page. Today, though, we’ve shipped a new way to easily post status page updates across all of your status pages right in the command center. To the right of the “resolve” button, you’ll now find a dropdown that pulls up a modal for adding status updates. Users of Slack will find a similar modal to what they’re used to using in Slack!

Bugs and Fixes

• 💅 For FireHydrant AI, We improved the status message drafting to make your status updates more precise.
• 💅 We also removed slack user ids from generated summaries (when drafted updates were trying to tag someone).
• 💅 In the command center, the milestone updating UI has been refreshed to match the Milestone tags in the dropdown in addition to some niceties like updating to one minute after previous milestone or setting a milestone to the current time.
• 💅 When paging from Slack, the incident name and description are automatically filled in as a template to improve ease of use.
• 💅 When looking at MTTX analytics, we added a direct link to the “number of incidents” chart to be able to quickly view which incidents are included in the data. Users can now also download a CSV of incidents from that linked view.
• 💅 We improved the drawer in the MTTX analytics view, making an easier button for opening the side drawer for any of your group-by data points.
• 🐛 We fixed a bug where if you have multiple Jira Cloud instances connected, tickets were intermittently being opened in the wrong instance
• 🐛 We fixed an issue where any execution conditions combined with “Current milestone is…” were failing to evaluate.
• 🐛 We fixed an issue where we still posted impact and milestone notifications to Slack even if the setting was set to off
• 🐛 We fixed a bug where role assignments would show up multiple times even if it was the same user being assigned to the same role
• 🐛 We fixed a bug where the edit button on Runbook steps wasn’t working
• 🐛 We fixed an issue where a user with Viewer permissions would open an incident an alert and downstream actions like linking the alert didn’t work due to insufficient permissions

Today, FireHydrant is excited to announce AI-powered Incident Management as part of our platform. Our AI features are designed to enhance how you handle incidents, making every step from detection to retrospective faster, more intuitive, and less cumbersome.

💬 AI-Powered Incident Summaries

Incident Summaries provide immediate, clear insights into incidents, streamlining the response process and enhancing team coordination. These summaries are designed to quickly onboard new responders and maintain ongoing situational awareness for all team members. You can access summaries right in Slack by running /fh summary or visit the new Summary tab in the command center for the latest updates! Want to learn more? Read up on summaries the docs.

🎥 AI-Context from Zoom Transcripts

FireHydrant's Zoom-aware context enriches your incidents with insights directly from Zoom meeting transcripts, ensuring comprehensive situational awareness for all team members, regardless of their physical presence in bridges. Never worry about scribing live calls again, FireHydrant will take care of that for you. To learn more about installing and using our updated Zoom integration, check out the docs.

📝 AI-Drafted Retrospectives

Get a head start on learning from every incident with FireHydrant's AI-Drafted Retrospectives. This feature leverages AI to create detailed drafts for your retrospectives, incorporating essential incident insights and facilitating a focus on discussion and improvement. All fields on a retrospective, including Description, Customer Impact, and Lessons Learned. To read more about drafting Retrospectives with AI, checkout the docs.

📣 AI-Drafted Status Page Updates

Elevate your incident communication with drafted status updates. This feature simplifies the creation of clear, concise, and audience-appropriate status updates, reducing the cognitive load during high-stress incidents. Use AI-Drafted updates from the Slack command /fh update or use the new Updated Incident button in the command center. Read more about AI-drafted Updates in the docs.

Getting Started with AI

To access the new AI features in FireHydrant, navigate to your organization's AI setttings page (Settings > AI). Locate the the Enabled toggle and click it to turn on all AI features for your FireHydrant organization. Learn more about all our AI feature in our docs.

We launched Signals to the world to improve and simplify the on-call process for everyone. We have been hard at work to go even further in making Signals even easier. You can try Signals today by signing up for an account or reaching out to our team. Read on for some of our latest updates!

Team Webhooks to Alert a Team

While Alert Rules are powerful ways for teams to filter and create Alerts from any incoming webhook, there are times when you just need to directly send an alert to a team. Whether you’ve already configured filtering on your monitoring tool or just want to be able to directly send an alert to a team, you can now use the team-based webhooks to send alerts to a team’s default escalation policy. You can grab a webhook for any team and for any monitoring tool that FireHydrant supports. Check out the team webhooks either on our Event Sources page in Signals or the updated Alert Triggers page on any team.

Resolved State for Alerts

Not every alert from your monitoring tools needs to become an incident where you assemble the team and remediate the root cause issue. And so early on at FireHydrant, we made the decision that Incidents and Alerts needed to be distinct. Sometimes, a single on-call engineer can remediate an issue without raising the broader alarm. For instances like this, we added a Resolved state for Alerts so that your team can easily mark alerts as resolved, and your team can track resolved alerts as well as resolved incidents to better understand the full picture of your on-call and incident management process. And when you open an incident from an alert, we’ll automatically resolve the alert when the incident is resolved.

Signals API Endpoints are Live

Just like you would expect with any developer tool, you can build your own custom integrations and tooling on top of FireHydrant. We’ve opened up our public API usage for all of the endpoints that power Signals including On-call schedules, Escalation Policies, Alert Rules as well as Alerts. We’re excited to see what you build, and you can get started by visiting our API documentation or using our updated Go Client.

Fixes and Bugs

• 💅 Updated the Slack Alert message to include links to the Incident Command Center and Slack channel
• 💅 Added escalations as a threaded response to the Slack Alert message.
• 💅 Changed the Slack Alert message open incident flow to use the Declare Incident modal in Slack
• 💅 Added email notifications when a shift has been claimed
• 💅 Added Slack channels IDs to our Terraform provider
• 💅 Added team slugs to our Terraform provider
• 💅 Updated all transposers to auto-close flappy alert
• 💅 Added MTTx metrics for Alerts to Analytics pages and API
• 💅 Updated schedules to show in a users timezone regardless of schedule setting
• 💅 Cleaned up schedules UI to make editing and viewing easier.
• 🐛 Fixed issue with Alerts coming from DataDog to properly split tags on commas

Today, we’re excited to announce the GA release of Signals, the alerting tool for modern devops teams. Read more about launch on our blog post.

Schedules that Work for You

FireHydrant now comes with team based on-call schedules, making coordination of notifications and incident management a breeze. Schedules are incredibly flexible, allowing you to create schedules that match your teams’ needs. As easy as managing a Google Calendar, on-call schedules in FireHydrant allow you to quickly re-assign shifts or even portions of a shift. Users can easily request coverage from their team without needing an override or a whole schedule recreated. Escalation policies in FireHydrant make it easy to set up your on-call program for each team. Escalation policies will route incoming Alerts to on-call schedules, users, or even Slack channels and allow you to set up multiple escalation steps when an alert is escalated. Any step in an escalation policy can route Alerts to multiple targets, making rotations like follow-the-sun coverage a breeze. An escalation policy can also repeat as many times as you like and ultimately can hand an alert off to another team (using their default escalation policy).

Alerts In Your Control

Alerts in Signals start with incoming events, most of which can be easily created from webhooks. Signals comes with a simple HTTP webhook as well as many provider-specific webhooks to make sure the data gets properly ingested. Events can include a variety of data including your services and other catalog components to make sure Alerts are actionable for your responders. Events are just the start, though, because Signals is a declarative Alerting system: we only create alerts for the events that matter to you. Each team can create and maintain their own Alert Rules that take incoming events, look for specific data in the payload, and then create Alerts that are sent to an escalation policy, an on-call schedule, or a specific user. Alert Rules use CEL expressions to help you create highly specific and powerful rules for matching incoming event payloads.

Get Notified Where You Are

On-call users can easily receive Alerts where they need, including our brand new iOS and Android apps. Users can configure their own notification preferences which include SMS, WhatsApp message, voice calls (where supported), mobile app notifications, email, and of course, Slack. Regardless of where they receive notifications, users can quickly respond to alerts: acknowledging, escalating, dismissing, or even quickly opening an incident from them.

Integrated into Incident Management

Signals integrates seamlessly into your incident management practices. Easily declare incidents from an Alert to assemble your team. You can even create Runbook steps to pull in on-call engineers and send alerts to responders about new incidents. And speaking of incidents, in FireHydrant, Alerts and Incidents are separate concepts. Not every alert ultimately becomes an Incident, an important distinction not only for your incident management process, but also for understanding the effectiveness of your alerting pipeline when reviewing your data. To get started, read our Signals Documentation and reach out to our team about trying Signals today.

Status Update Templates

Do all your status page updates look similar after a while? Have one flaky service where you know exactly what you’d tell your customers and stakeholders if someone told you there was an outage? Tell that to status pages! We’ve created status update templates that you can configure in settings. These will allow you to pre-fill out common updates to a status page, so that you have a place to start from when updating an incident from slack. Configure these today by going to Settings > Status templates, and using them the next time you run “/fh update”

Improving your Follow Up

Whenever a follow up is filled out, they usually could use some incident specific data in them as well. Today, we’re announcing changes that will make it easier for you to pull in incident information as you create a follow up. We’ve highlighted the liquid enabled fields and added some help text that’ll highlight where liquid templating is available and how to use it. Try this out by opening up a follow up from either Slack or the Web UI to see how it works today!

Other Changes and Bug Fixes

• We added the ability to toggle off Incident Types in Incident Settings
• We added guardrails stopping you from navigating away from unsaved work on a retrospective
• We added the ability to toggle Priority off in Organization Settings
• We added copy to clarify what’s about to happen when testing a runbook
• We added details about liquid context to runbook configuration for custom fields
• We fixed a bug where duplicate catalog items could be displayed on the teams page

Improvements to Jira Integration Configuration

Jira configuration, especially as a non-Jira expert has always been difficult. We’re super excited to tell you that it’s getting a little bit easier. We’ve improved the user experience around configuring jira as well as updated the copy to make it clearer what each button in Jira configuration does. If you need to set up a new Jira configuration, feel free to try it out, by adding a Jira Cloud connection in Settings > Integration

Analyzing Incident Source

When incidents happen, everyone is always concerned with “how did we find out about this,” as more organizations aim to find problems ahead of their customers through enhanced automation and alerting. For all of our new customers, we’ve added a field for “discovered by,” allowing customers to better capture how they found out about an incident, and understand if their automation efforts are working through our new analytics tooling. For existing customers - you’re not left behind! The new field works on the same system as our existing custom fields, and you can manually add it via Settings > Incident Settings. Then, once you’ve populated that field on incidents, use MTTX analytics to understand where the bulk of your incidents come from, and which ones take the longest to resolve!

Improved Error Reporting

Debugging is an awful rabbit hole. We’ve all found ourselves in situations where we find a hidden error, fix it, and are blessed with 20 new errors that we’re now newly aware of. Today, we’re happy to report that we’ve been hard at work to give more transparent and descriptive error messages that will hopefully help you identify when and where things are going wrong across Jira, PagerDuty, and Webhooks.

Misc Bugs + Fixes:

• Fixed a front-end issue where runbook conditions and scheduling could be misaligned to the modal
• Added linked alerts support to OpsGenie
• Fixed an issue with associating services to teams

The most difficult part of the incident response process is learning from it, and learning from incidents without having data is like searching for the perfect piece of chocolate in an assortment box: time consuming, with lots of squinting at the little cards that tell you what you’re getting. Today, we’re announcing general availability to our analytics that will make it easier for you to find exactly the data you’re looking for in FireHydrant’s analytical box of chocolate.

MTTX Analytics

MTTX analytics is designed to help you find your baseline mean-time-to metrics and then break the MTT* metrics across any dimension. This applies across all metadata in FireHydrant: from Services, Environments, and Functionalities to provide incident response context across technology areas; to Users and Teams to help you identify who might be at the most risk of burnout. You’ll also be able to see how each of these compares to your baseline MTTX, and filter it down to see how specific types of incidents impact any of these dimensions in context.

Data Trust and Cleanliness Views

As you look at MTTX analytics, there might be times when the data you see doesn’t match your intuition. We’ve added views in MTTX analytics that will help you validate, and clean the data that we’re using as our inputs to MTTX analytics. By clicking on the number of incidents next to a metric, you’ll not only be able to see the metrics for those specific incidents, you’ll be able to go directly into those incidents, and “clean up,” editing milestone times and metadata. You’ll even be able to identify incidents that did not get correct metadata, looking at incidents grouped under No Impacted Functionality/Service/Environment/… really any metadata that you might care to pull in. Any updates to metadata will update in real time, allowing you to see the impacts of your changes immediately.

MTTX Over Time

After getting context on different dimensions as compared to the baseline, you’ll probably be asking the question of “has it always been this way?” Fortunately, we have the answer! By clicking on any grouping, you’ll be brought to a drawer that will show you not only Analytics for that particular grouping, but how those analytics have changed over time, and if there’s any need to be concerned. Find the service that has been progressively less reliable over time today, use it to make the case for proactive improvement.

We’re in love with these new improvements to analytics, and we hope they help you find the perfect piece of chocolate (data) in the deep box that is incident response data. To find the new analytics, navigate to MTTX Analytics, by clicking the Analytics button in the top nav of app.firehydrant.io and dive in. Happy Firefighting!

Slack Channel Selector

Recently, we did some work to make it easier to select the slack channel where you want to send your messages, by adding a slack channel selector. With this change, there's no need to manually type your slack channels into the selector (though you still can, and can use Liquid Templating as needed), and will now allow you to choose from all of the channels that FireHydrant can see.

Onboarding Experience Updates

We’ve updated our onboarding experience to make learning about how FireHydrant works easier and faster! As part of this, we’ve added new options to our help menu, hidden fields without selectable options from the incident declaration form, and added padding to corner cases to help out if you get stuck while getting set up with FireHydrant in slack. This should make it even faster and easier to get your team running incidents through slack.

Additional Bugs and Fixes

• We updated permission for saved searches and now all roles can manage saved searches
• We fixed a bug where the “Yes, open” button would fail to show for alerts in Slack.
• We brought back the checklist template option when creating a checklist in Slack.
• We added a help option for “/fh resolve” in our Slack help menu.

In Beta: Service Catalog and Team MTTX Analytics

Analyzing incident response is one of the most important pieces of the incident response process, as improvement without being data driven is a little like fumbling around in the dark. If you’ve been trying to analyze your incident response metrics and struggling to understand the greatest opportunities for improvement, we have good news for you, because today, we’re announcing our open beta for our a new analytics experience.

In MTTX analytics, you’ll be able to see your baseline MTTX metrics, filter them to incidents with specific metadata (such as tags, custom fields, etc), and break out incident metrics for different Services, Environments, Functionalities, Teams, Users, and Severities. This is intended to allow you to view the difference in incident response process between different parts of your organizations or types of incidents, as well as understand which teams and individuals are under the greatest incident load. Give MTTX analytics a try and let us know what you think either through a support ticket or your CSM!

Fine-Grained Slack Messaging Controls

Slack is noisy, and our lives are all ruled by it. Unfortunately, because it’s where we do most of our work, it’s also the ideal spot to put responses, notifications, and information pertaining to incident response. Today, we’re giving you greater control over the messages that are posted into Slack from FireHydrant by launching our fine-grained Slack channel notification preferences. If you navigate to your Slack Configuration > Channel Notification Preferences you will have the the choice between silent (no notification), channel notifications, threaded notifications, or threaded that also post to the channel. You can configure this for team assignment, role assignment, incident milestone & impact updates, incident updates, task updates… you get the point, go check it out for yourself!

Multi-Select Retrospective Questions

Retrospectives are critical to the incident response process to ensure that all relevant data is captured to help in future incident remediation and prevention. Today, we’re announcing improvements to your ability to do that using FireHydrant retrospectives, by using multi-select questions. You can edit or add a new question to your retrospective template by navigating to settings > Retrospective Configuration and adding a new multi-select question. Any new multi-select questions will show up on retros for incident declared after the new question is created.

Liquid Templating Improvements

We launched a new liquid templating experience to help you when building out runbook steps. You can now browse a list of commonly used snippets to quickly insert a template to your runbook step. And if you really want to dig into the details, there's a new Preview experience that allows you to see how your liquid templating will look with real incident data. This makes it even easier to use liquid templating to create powerful and useful runbooks for your team.

Additional Fields for Status Pages

Following-up on our updated status pages, we've added a few new Incident Fields that you can publish to your status pages. To help folks who are building internal-facing status pages, you can now add direct links to the Incident Command Center in FireHydrant, the connected Slack Channel, and the meeting bridge (Zoom, Google Meet, or Webex).

Markdown support in tasks and task lists

Tasks and task lists are great ways to keep your team focused on the work that needs to happen during an incident. Now, you can create even richer tasks (and lists!) by using Markdown to add context like links and lists. Markdown will be rendered in Slack and in the Command Center so that you can easily get more context about any task.

Filter and Search on Scheduled Maintenances

The Scheduled Maintenances page got an overhaul including the ability to filter, search, and save views. For teams managing a number of scheduled maintenances, this improvements makes it easier to get to the scheduled maintenances that you care most about at any given time.

Additional Bugs and Fixes

• We fixed an issue with inactive teams triggering runbooks conditions
• We fixed an issue with older incidents not updating the channel name
• We fixed a permissions issue that blocked some users from starring events in the timeline
• We fixed an issue where images were not showing up in the retro PDF export

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.