Whenever a new customer joins incident.io, we make notes on what made them chose to buy our product and, if we were in a competitive process, why they chose us over other providers they were evaluating. It’s a lot of messy data and raw notes, but contained within is a veritable treasure trove of customer feedback. Summarising large amounts of data? Sounds like the perfect job for an LLM.

We approached building a Terraform integration with a sense of trepidation. One of the things that motivates us is building features we think people are going to love using, and Terraform integrations are often not that. Terraform integrations have a number of common pitfalls. Building resources by hand is tedious, and requires deep understanding of their specification. Importing and managing existing resources is also often painful.

Clean, clear, and ready to be customized to suit your needs. Google Docs Having a dedicated incident post-mortem is just as important as having a robust incident response plan. The post-mortem is key to understanding exactly what went wrong, why it happened in the first place, and what you can do to avoid it in the future.

Remind yourself of the worst incident your organization has faced. If you’re lucky it might have been your entire service being offline for a period of time. Less lucky, and perhaps you encountered something affecting the sensitive data your organization is the custodian of. Whilst uncommon, incidents of this severity happen to every organization at some point. This criticality of situation is what many refer to as a Sev0, the most severe of incidents.

When an incident strikes, it often brings a whirlwind of stress for everyone involved—from the teams directly handling the issue to the stakeholders making crucial decisions. Imagine support teams on high alert, customers anxiously awaiting resolutions, and executives probing for answers to steer the company through turbulent times. This mounting pressure can make a challenging situation nearly unmanageable, especially when faced with problems that are new or unexpected.

We went live with our first set of AI-enabled features a few months ago. Needless to say, we learned a lot along the way, as this was the first time we had experimented with generative AI. Here, I'll share some of what we've learned as we’ve grappled with using LLMs to power new products at incident.io. This will be most applicable to the application layer, AI-enabled but not AI companies.

There’s no two ways about it: on-call is stressful. But with humans at the center, it’s especially important to find ways to make it as manageable and empathetic as possible. In this webinar with our friends at ELC, incident.io VP of Engineering, Noberto Lopes, and Intercom Staff Product Engineer, Andrej Blagojević, discuss their own experiences with on-call, and how the process can be better.

The launch of On-call was an integral part of the incident.io mission to become the single place you turn when things go wrong, and recently we hosted a live virtual event to show how it all came together. In this event, incident.io Co-founder and CTO Pete Hamilton sat down with incident.io Product Manager Megan McDonald, Product Engineer Rory Bain, and fellow Co-founder and CPO Chris Evans to demo the product, discuss the journey of the creation, and expand on what’s next.

At incident.io, “We care about our customers” isn’t just a talking point. It’s a core part of how we operate. Whether it’s a big feature request or a small bug fix, we’ve been intentional about making sure that customers always feel heard and seen—no matter the ask. But it’s not just that.

In the fast-paced world of software development and product delivery, incidents are often viewed as unwanted disruptions. Traditionally, incident management might only trigger for critical issues, like complete system outages, data loss of some kind, or security-related ones - you don’t need to go back that far for a few that were very serious: Heartbleed, xz utils, and more.