Operations | Monitoring | ITSM | DevOps | Cloud

88% of online consumers are less likely to return to a site after a bad user experience. This means that addressing frontend issues such as slow load times, broken features, and unresponsive elements is crucial. Frontend monitoring helps development and IT teams proactively catch and resolve these issues to improve their user experience.

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.

For years, Fender Musical Instruments has been synonymous with iconic guitars and amplifiers. But in recent years, the company has expanded its legacy into the digital realm, offering tools like Fender Play, an innovative learning platform for aspiring musicians. Behind this digital evolution lies a focus on delivering exceptional user experiences for its consumer-facing applications—a mission supported by Honeycomb for Frontend Observability.

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 it. As such, humans are part of the alerting loop, and alerts can be framed as devices used to redirect our attention. In this post, I want to drive this concept a bit further.

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. In R&D, there is always more to do. There is always more to research, design, build, fix, maintain, and improve. Spread across multiple domains, the possibilities multiply: we’re spoiled for choice—and, while inspiring, the breadth of possible investment areas can be overwhelming.

Are you trying to wire your React application to Honeycomb, but running into some challenges understanding how our instrumentation works with React? 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. These examples use a React application created with Vite.

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. AI tools, and especially LLMs, are growing incredibly quickly, and I feel that these tools have a ton of potential.