Operations | Monitoring | ITSM | DevOps | Cloud

I recently wrote an update to my old piece on the cost of observability, on how much you should spend on observability tooling. The answer, of course, is “it’s complicated.” Really, really complicated. Some observability platforms are approaching AWS levels of pricing complexity these days.

The session.id field is special in Honeycomb for Frontend Observability. It’s a default option for filtering and grouping, and it’s the basis for session timeline analysis (in Early Access). Now you can control how session.id is set. In prior releases (< 0.15.0) of the Honeycomb Web SDK, we used our own UUID generator for session.id, and it was not accessible outside of the Web SDK itself. As of version 0.15.0, we give you full control.

In Honeycomb’s Customer Architects team, we work with the full spectrum of team, scope, and budget sizes. “The data isn’t valuable enough” is something we’re always dismayed to hear, but we hear it often enough. The thing is, as much as we want it to not be true, no product or tool can magically maximize the value of your telemetry data—at least not without gobs of human input, oversight, and review.

In 2018, I dashed off a punchy little blog post in which I observed that teams with good observability seemed to spend around ~20-30% of their infra bill to get it. I also noted this was based on absolutely no data, only my own experiences and a bunch of anecdotes, heavily weighted towards startups and the mid-market tech sector. This post should have ridden off into the sunset years ago. To my horror, I have seen it referenced more in the past year than in all preceding years combined.

Seems like you can’t throw a rock without hitting an announcement about a Model Context Protocol server release from your favorite application or developer tool. While I could just write a couple hundred words about the Honeycomb MCP server, I’d rather walk you through the experience of building it, some of the challenges and successes we’ve seen while building and using it, and talk through what’s next. It should be pretty exciting, so strap in!

We’re excited to share that Honeycomb has completed our first-ever acquisition: we’re joining forces with Grit, bringing on board not only a strong team, but also compelling technology that supercharges our ability to deliver on our mission: to bring observability to every software engineer. This is a strategic move that will help us deepen the value we deliver to customers and accelerate our vision for what modern observability can and should be.

For years, organizations have used the term “observability” as an evolution of monitoring, a discipline practiced by operations teams to understand whether production software was working. I’ve been annoyed by this—not because it’s philosophically wrong, but because it diminishes the importance of observability as a generalized software engineering practice.

You can’t throw a rock without hitting an online discussion about ‘vibe coding,’ so I figured I’d add some signal to the noise and discuss how I’ve been using AI-driven coding tools with observability platforms like Honeycomb over the past six months. This isn’t an exhaustive guide, and not everything I say is going to be useful to everyone—but hopefully it will clear up some common misconceptions and help folks out.

At Honeycomb, we believe that observability should be accessible, effective, and transformative. That’s why our customer education team is thrilled to introduce Honeycomb Academy, a learning hub designed to help our customers of all experience levels master observability, OpenTelemetry, and the Honeycomb platform.