Operations | Monitoring | ITSM | DevOps | Cloud

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.

At Honeycomb, we’re actively growing our design system, Lattice, to ensure accessibility, optimize performance, and establish consistent design patterns across our product. One metric we use to measure Lattice is the adoption of components across the product. Adoption is about understanding how, where, and why they’re being used.

CloudWatch metrics can be a very useful source of information for a number of AWS services that don’t produce telemetry as well as instrumented code. There are also a number of useful metrics for non-web-request based functions, like metrics on concurrent database requests. We use them at Honeycomb to get statistics on load balancers and RDS instances. The Amazon Data Firehose is able to export directly to Honeycomb as well, which makes getting the data into Honeycomb straightforward.

Take a drink if you hate that term. Tim O’Reilly has written a post about the huge shift AI is making with our relationship to software engineering (read: The End of Programming as we Know It). Scary title. But the content is less so. Why?

Last week marked the inaugural HumanX conference, a convening of leaders, technologists, policy makers, and media, all brought together to discuss the state of AI and its potential impact on the future of software, business, and society.

Observability and monitoring are not about gathering different data—they differ in their purpose, but share the same data. Monitoring is focused on notification based on predefined questions. Whether that’s through Dashboards people watch, or push-based alerts to notification systems like SMS or purpose-built platforms like PagerDuty.