One of the hardest parts of my job is to get people to appreciate just how much of a difference Honeycomb/observability 2.0 is compared to their current way of working. It's not just a small step up or a linear improvement. Rather, it's an entire step change in the way that you write, deploy, and operate software for your customers.

Since its early startup beginnings in Amsterdam, Booking.com has redefined the travel industry, establishing itself as a premier platform for millions of travelers worldwide. With over 28 million accommodation listings and a staggering 1.5 million room nights booked every day, Booking.com operates on a scale that demands a robust and constantly monitored infrastructure.

Back in Alerts Are Fundamentally Messy, I made the point that the events we monitor are often fuzzy and uncertain. To make a distinction between what is valid or invalid as an event, context is needed, and since context doesn’t tend to exist within a metric, humans go around and validate alerts to add this context. As such, humans are part of the alerting loop, and alerts can be framed as devices used to redirect our attention.

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.