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.

In this article, I’ll clear up the confusion around Cross-Origin Resource Sharing (CORS), specifically discussing preflight requests, which are the bane of engineers everywhere.

Another one in the history books: 2024 is (almost!) over. The OpenObservability Talks podcast, hosted by Dotan Horovits, recently featured a lively discussion with Charity Majors, Co-founder and CTO of Honeycomb, to reflect on the trends, achievements, and future of observability.

All the conditions necessary to alter the career paths of brand new software engineers coalesced—extreme layoffs and hiring freezes in tech danced with the irreversible introduction of ChatGPT and GitHub Copilot. Recession and AI-assisted programming signaled the potential end of a dream to bootcamp-educated juniors. 

Have you ever had an alert go off that you immediately ignore? It’s a nuisance alert—not actionable—but you keep it around just in case. Or maybe you’ve looked at a trace waterfall and wondered what exactly happened during a gap that just doesn’t drill down deep enough to explain what’s going on. Do you know the feeling where you have just enough information to monitor what’s going on in your systems, but not quite enough to put your mind at ease?

Honeycomb engineers were amongst the earliest adopters of this technology. Not in the widely parodied top-down, VP-mandated, “go be AI leaders nao plz” kind of way, but in a bottoms-up, experimental kind of way, driven by curiosity and fascination.

Refinery is a powerful tail-based sampler—but with great power comes great challenges. We heard your feedback and are excited to announce the release of Refinery 2.9, a rather large update that is packed with goodies to make your life easier when running Refinery in your network.