Automated event payloads come in many shapes and sizes. These infinitely different event structures pose a problem for users who want to send them all to the same place to page on-call staff. Unless that on-call solution supports the schema directly, you’re out of luck. While we’re proud of the number of integrations we support today for event sources into on-call, we also think the best number that we should support is infinity.

Today, the entire world is feeling the pain of a major software outage. While we know a lot about these occurrences—our entire business is built on helping companies manage incidents and outages effectively—we’re not here to share our opinion on it. Instead, we’d like to help those unfamiliar with the incident lifecycle understand what happens when an outage like this occurs, who is responsible for what, and what companies ultimately do to get things working again.

We’ve gotten clear feedback from our customers that we’ve needed a strong Microsoft Teams integration. Responders want a full suite of incident management functionality, no matter what chat application their organization uses. We heard you. That’s why we’re proud to announce a brand new MS Teams integration with fully robust incident management lifecycle capabilities.

When we launched Signals to the world, we were excited to hear how our product resonated with many teams. But with that excitement came an understandable concern: how much time and effort will I have to put in to move from my existing provider to Signals? We hear you — that’s why we built the Signals Migrator tool. And we’re open sourcing it.

Over the last five years we’ve seen our customers run 583,954 incidents more efficiently thanks to a shared workspace, powerful Runbook automations, and auto-captured data. Yet despite a great deal of progress, incident efficiency hasn’t achieved peak potential. We talk to a lot of folks that are still stuck in the muck: new responders struggle to get up to speed quickly, incident commanders wade through post-incident drudgery, and knowledge silos prevent comprehensive improvements.

FireHydrant is mission-critical infrastructure for thousands of engineers. It’s our job to be up – even when everything else is down. Here's a technical look at how we tested Signals alerting and on-call to ensure high availability and speed.

Is your DevOps tool stack out of control? I feel like every day, I talk to someone who feels this pain. The technological golden age of the past few years created a lot of niche tools, but now that CFOs and boards alike are demanding budget restraint, many of these tools are being scrutinized. The reality of the situation is that it’s not good enough for a tool to do one thing anymore.

TL;DR You deserve a better alerting and on-call tool. So we built Signals. In our early days, we often used the tagline, “You just got paged. Now what?” It encapsulated how FireHydrant solved for all of the messy bits that come after your alert is fired, from incident declaration all the way through to retrospective. At the time, we saw alerting and on-call scheduling as a solved problem.

Analytics are great. We can all agree there. But not all analytics are created equal. FireHydrant has long offered incident analytics dashboards that provide an in-depth look at the entire incident lifecycle. You can see how incidents impact services and teams, understand retrospective participation and completion, and even get insight into follow-ups. But great analytics do more than simply organize data. They help you tell a story.