There are a limited number of investments that a team can make in any given year and it can be daunting to choose the “right” ones. To simplify our options, I keep coming back to "the future" and "the floor."

Ever since January of 2022, we have had an employee representative seated on our board of directors. Paul Osman was the first employee to hold the position; when he left the company, Alyson van Hardenburg took over and filled out the rest of his time; we then nominated her to serve another year in that seat.

In this article, I’ll lay out approaches for wiring Honeycomb to client-side only React so you can ingest your telemetry into Honeycomb and take advantage of the Web Launchpad. This telemetry sends semantically-named attributes, and can be used with any OTLP destination.

We recently released Refinery 2.9, which came with great performance improvements. Reading through the release notes, I felt the need to write a piece on this improvement, as it's quite important but easy to overlook: collect loop taking too long. This is the story of how we used distributed tracing to find the slowdown in this loop.

I’ve read a steadily increasing stream of articles about using AI in SRE, and I have yet to find one that inspires my trust. Each article makes impressive claims about the capabilities of AI and the way it can be applied to SRE tasks, but the vast majority are light on details.

In speaking with frontend engineers this past year, I realized that understanding the power of wide events is a big mental shift. We’re used to having metrics—think the P70 of your Core Web Vitals, or the average Time To First Byte (TTFB). These are high-level numbers that give us some insight into the average user experience on your apps—but wide events help us do so much more than metrics can ever dream of.

At Honeycomb, we believe in ensuring an awesome developer experience for our own engineering teams; it's the only way that we can compete with companies that have way more engineers than we do. We've historically tried to keep our build times under 15 minutes, taking percussive action when build times got over 15 minutes.

Gearset knew it was time to level up their observability strategy. To deliver the reliability and responsiveness their customers expected, they needed a more powerful way to pinpoint and solve issues—one that could keep pace with their rapid growth. That’s when they turned to Honeycomb.

As a software engineer, I’m always evaluating tools and technologies that can optimize my workflow. Developer productivity isn’t just about writing more code—it’s about reducing friction, whether that’s context-switching, making repetitive edits, or understanding unfamiliar parts of a codebase. That’s where Copilot comes in: making tasks that once felt monotonous or time-consuming into faster, more intuitive processes.

The Collector is one of many tools that the OpenTelemetry project provides end users to use in their observability journey. It is a powerful mechanism that can help you collect telemetry in your infrastructure and it is a key component of a telemetry pipeline. The Collector helps you better understand what your systems are doing—but who watches the Collector?

The OpenTelemetry Collector is an exceptional solution for proxying and enhancing telemetry, but it’s also great for generating telemetry from machines too. In this post, we’ll go through a basic, opinionated setup of using the OpenTelemetry Collector to extract metrics and logs from a Windows server.

Logs are more than just records. With proper log monitoring, they become the honey that sweetens observability. Observability is your ability to understand and optimize your system’s behavior. Turning raw logs into actionable insights requires the right tools, practices, and insights. This blog post is a guide on log monitoring key concepts and best practices for sweetening your observability.