The most successful software development movement of my lifetime is probably test-driven development or TDD. With TDD, requirements are turned into very specific test cases, then the code is improved so the tests pass. You know it, you probably use it; and this practice has helped our entire industry level up at code quality. But it’s time to take a step beyond TDD in order to write better software that actually runs well in production. That step is observability driven development.

Practicing observability isn’t just about tools. It also means improving how you work together and how you share lessons across the team. Learning from each other helps everyone on your team become better engineers that can create amazing experiences with code, or that make code work at incredible scale (or both!). Writing software and operating it in production is—and must be—a team sport.

Pretty much every organization of any size is paying close attention to the adoption of security practices in order to manage and protect their most sensitive data, including personal identifiable information (PII), personal health information (PHI), or other customer and financial data. For any team using SaaS tools, data protection is a table-stakes requirement. For compliance regulated industries — banking, financial services, healthcare.

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...