At a recent training session, Jeli spent a great deal of time covering incident retrospectives and what makes an incident worthy of studying. My colleague Ben Hartshorne asked a fascinating question, which I’ll paraphrase here: We’ve been talking about what makes an incident interesting, but what about the reverse? Are there aspects of an incident that would make you say, “We probably shouldn’t bother doing a retrospective on this one?”

When your alerts cover systems owned by different teams, who should be on call? We get this question a lot when talking about SLOs. We believe that great SLOs measure things that are close to the user experience. However, it becomes difficult to set up alerting on that SLO, because in any sufficiently complex system, the SLO is going to measure the interaction between multiple services owned by different teams. Therefore, the question becomes: who gets woken up at night when an SLO is burning through its error budget?

Honeycomb's Deployment Protection Rule for GitHub Actions quickly enables canary deployments by letting you use Honeycomb query results to prevent deploying to your next target environment.

Refinery, Honeycomb’s tail-based dynamic sampling proxy, often makes sampling feel like magic. This applies especially to dynamic sampling, because it ensures that interesting and unique traffic is kept, while tossing out nearly-identical “boring” traffic. But like any sufficiently advanced technology, it can feel a bit counterintuitive to wield correctly, at first.

We’re in Amsterdam for the week of Kubecon EU. Come by our booth to learn more about how you can gain complete observability into your Kubernetes clusters with Honeycomb and OpenTelemetry. In the meantime, enjoy this OTel update!

Contrary to Betteridge’s Law of Tabloid Headlines, the answer to the question, "does OpenTelemetry in .NET cause performance degradation?" is yes, but context is important. I get this question so often that I thought it was time to get some stats on it.

Spring has sprung, and the bees have been busy. Let’s have a look at what’s new in Honeycomb at the close of March.

The future of observability has never been more exciting, and this latest round ensures we can continue to invest—with conviction—in improving the lives of software engineering teams. We hope this is a moment of welcome change from the soul-crushing headlines plaguing the tech industry these past few months. 

Last month, I had the opportunity to join Jen Dary on her podcast, Be Plucky. The conversation was great, and we covered a lot of topics. We unpacked the merits and nuances of growing as a generalist and/or a specialist. I also had the chance to reflect on and share my experience in changing roles and making a few specialization shifts in my career. 

The Twelve-Factor App methodology is a go-to guide for people building microservices. In its time, it presented a step change in how we think about building applications that were built to scale, and be agnostic of their hosting. As applications and hosting have evolved, some of these factors also need to. Specifically, factor 11: Logs.

Dear Miss O11y, I want to make my microservices more observable. Currently, I only have logs. I’ll add metrics soon, but I’m not really sure if there is a set path you follow. Is a guide of some sort, or best practice, like you have to have x kinds of metrics? I just want to know what all possibilities are out there. I am very new to this space.

The open source community talks a lot about the problem of aligning incentives. If you’re not familiar with the discourse, most of this conversation so far has centered around the most classic model of open source: the solo unpaid developer who maintains a tiny but essential library that’s holding up half the internet. For example, Denis Pushkarev, the solo maintainer of popular JavaScript library core-js, announced that he can’t continue if he’s not better compensated.