Asking engineers to be on-call is usually a tough sell. Think about it: if someone asked you to add even more to your already packed workload, that would be a difficult proposition to say yes to. And that’s before you mention that this work typically happens late into the day and even (some) sleepless nights. Companies need to have an on-call function to keep their services and products running smoothly—it’s practically a non-negotiable at this point.

For financial services companies, good incident management is absolutely critical—maybe more so than in other industries. So, for Michael Cullum and his team at Bud Financial, the choice to build an incident response tool felt right for them in the moment. But very quickly, Michael and the team came face-to-face with the myriad limitations that come with building your own response tooling.

Recently we went live with one of our biggest product launches to date AI. And this product was unique in that it was broken up into four smaller projects: So naturally most folks might be wondering: What were the biggest differences between these projects and what went into actually building out each of these features? In this episode, you'll hear from Rob and Isaac, both Product Engineers who played a really critical role in the building out of related incidents, to get a peek behind the curtain.

With the world still working out the limits of LLMs and ever more powerful models being released each month, it’s a little hard to know where to begin. Whether it’s summarising and generating text, building a useful chat assistant, or comparing the relatedness of strings with embeddings, almost all of this now can be done via a few simple API calls. It has never been easier to incorporate these new technologies into your own product.

Like most things, our AI Assistant started out as an idea. One of our data scientists, Ed, was working with our customers to improve our existing insights. But the most common theme that kept surfacing was the wide-range of use cases that our customers wanted to use insights for. Using this user feedback as our inspiration, we came up with the idea of a natural language assistant that you can use to explore your incident data.

This week was a particularly exciting one for us at incident.io. We launched not one, not two, but four AI-powered features to help folks get the most out of their incidents. In this episode of The Debrief, we sit down with Ed Dean, Product Analyst, and Charlie Revett, Product Engineer, to talk through all of these features and discuss how they're already making a measurable impact. You'll also hear them talk about: You can learn more about our AI features here.

Since the advent of ChatGPT, companies have been racing to build AI features into their product. Previously, if you wanted AI features you needed to hire a team of specialists to build machine learning models in-house. But now that OpenAI’s models are an API call away, the investment required to build shiny AI has never been lower. We were one of those companies. Here’s our journey to building our first AI feature, and some practical advice if you’ll be doing the same.

One of the most painful parts of incident management is keeping on top of the many things that happen when you’re right in the middle of an incident. From figuring out and communicating what’s happening, to ensuring you learn from previous incidents, and even capturing the right actions – incidents are hard, but they don’t need to be this hard.

As we’ve talked about before, our app is a monolith: all our backend code lives together and gets compiled into a single binary. One of the reasons I prefer monolithic architectures is that they make it much easier to focus on shipping features without having to spend much time thinking about where code should live and how to get all the data you need together quickly. However, I’m not going to claim there aren’t disadvantages too. One of those is compile times.