I’ve tackled this question before: how much should my observability stack cost? While the things in that post are true now as ever, I did end on one somewhat vague conclusion. When it came to figuring out exactly what you need in your stack by drawing a straight line from the business case to the money you spend, my conclusion was that “it depends.” That’s how we approached pricing at Honeycomb: it depends on your needs, so we should give you many different options.

At Honeycomb, we’ve been listening to your feedback. You want easier ways to predict usage and scale your observability spend with your business. What would it look like to meet you where you already are, using similar terms, and give you more control with a simpler experience? We think that means reimagining the customer experience into one that centers around an event-based model. But what exactly is an event? What does that mean for your team’s observability journey?

Observability is more than tooling. Of course having the right tools in place so you can ask arbitrary questions about your environment, without having to know ahead of time what you wanted to ask, is critical. Finding the unknown unknowns is the coveted observability sweet spot. However, it’s the actual doing it that proves a bit more challenging especially when you’re weaning off legacy tools.

As engineering teams shift from delivering services on monolithic architectures to microservices and even serverless environments, developers are no longer just responsible for creating and maintaining their code. Shared ownership has become the new normal (or at least trending towards) and so they are now responding to production incidents and in some cases in the on-call rotation. Of course incidents vary in terms of impact, but they do take time away from innovation and creating new capabilities.

Starting today, you can use more of Honeycomb than ever before for free. That means more teams can start building up production excellence with features that were previously only available for paid subscribers.

When Charity and I started pitching Honeycomb, we had a “bit” we would do, on the importance of building for teams: I’d identify her as the {Kafka, Mongo, insert tech-of-the-moment here} expert on the team, identify myself as the newcomer, and pantomime awkwardly leaning over her shoulder to see how she debugged some unexpected behavior.

“It turns out,” said Liz, “it was not a giant pile of work to start adding those rich instrumentation spans as you need them.” Liz Fong-Jones was telling dev.to’s Molly Struve about an error she encountered while trying to update her dev.to profile. When she entered honeycomb.io into the Employer URL field, the app responded with an angry red box...