In this podcast, the three incident.io co-founders Stephen, Chris and Pete take a trip down memory lane, revisiting the story of how they came to found incident.io and the major milestones of the first 12 months in business.

Amazon recently concluded their five-day long conference, AWS re:Invent 2022. This year’s conference was hybrid with the company streaming a significant portion of their in-person conference for free. For ten years now, the event has seen attendees across the cloud continuum come together to learn, share and get inspired. This year was no different as we saw some of the biggest names in cloud computing make their presence felt at the conference in Las Vegas.

There is no denying that incident management is one of the most crucial processes concerning the service and business aspects of software deployment. Not having a robust system in place to address and remedy unfortunate incidents can lead to user dissatisfaction, which can ultimately take a toll on your business metrics. A suboptimal management system can also have adverse impacts internally if it prioritizes efficiency and speed of recovery to the point of neglecting employee well-being.

Wouldn’t it be nice to learn which parts of your service see the most incidents, or why one service experiences more Sev1 incidents than the others? It’s not always easy to see the full disruptive impact of an engineering incident. Even harder to see trends across incidents and over time. Developing incident insights that you can use to help guide and shape the way your team designs and operates your product takes time, careful consideration, team engagement and the right tooling.

In this post, we’ll dig into the difference between a bug and an incident, why alignment on how they are defined matters, and how to ensure you’re still learning from the issue, even if it’s “just a bug.”