In the same way as the business is likely ok with you writing developer-based tests (unit, automation, integration), instrumentation is the same. The conversation we need to have is that instrumentation, or knowing the system is healthy, is the work we need to do for the feature. In my opinion, it’s even more important than those.

At Intercom, we focus on customer experience above all—our service’s availability and performance is our top priority. That requires a strong culture of observability across our teams and systems. As a result, we invest a lot in the reliability of our application. But unpredictable failures are inevitable, and when they happen it’s humans that fix them.

In this blog, we’ll dive into debugging with the Core Analysis Loop, the functional requirements for a backend datastore that make this possible, and whether it makes sense to build or buy your own observability solution.

By giving an overview into datasets, traces, and spans, you’ll get a peek behind the curtain into how Honeycomb facilitates observability in the hopes of arriving at a place where identifying the source of errors, finding performance problems, or understanding how data flows through a large system is made easier.

“How do I get started on instrumentation with OpenTelemetry, while also following best practices for the long-term?” This article is all about taking you from A to Z on instrumentation. Learn how to create immediate observability and see traces in your application right away, without changing code—and more!

Here's what some of our customers had to say about Honeycomb features that they found value in right away.

Two of our folks went to Monitorama 2022, and they gleaned a few pearls of wisdom they'd love to share with you, including an unexpected, but surprisingly insightful talk on carbon impact reporting. Read more now.

A while ago, I wrote about how we track on-call health, and I heard from various people about how “expecting to be woken up” can be extremely unhealthy, or how tracking the number of disruptions would actually be useful. I took that feedback to heart and wanted to address the issues they raised, and also provide some numbers that explain the position I took with these metrics.

In the social world, there is no outside: we participate in the systems we study. I’ve noticed this in code: when I come to an existing codebase, I get a handle on it by changing stuff. Change some text to “HELLO JESS” and see it on the screen. Break something on purpose and see what fails. Refactor and find compilation errors. After I make some real changes and shepherd them into production, then I’m integrated with the code, I come to an understanding of it.

In this webinar based on our O'Reilly book, we go over the difference between observability and monitoring - and when to use which.

This post will talk about using a derived column to directly connect individual customer experiences to the cost of providing that service with AWS Lambda. By leveraging these tools, we can better understand when our product is used in costly ways, and also provide tooling to better analyze and understand the cost effects of configuration changes.