It’s an exciting time here at Honeycomb HQ—today, we’re thrilled to announce our recent fundraise led by Scale Venture Partners, and to welcome Ariel Tseitlin to our board.

In theory, Honeycomb is always up. Our servers run without hiccups, our user interface loads rapidly and is highly responsive, and our query engine is lightning fast. In practice, this isn’t always perfectly the case — and dedicated readers of this blog have learned about how we use those experiences to improve the product.

I’ve said this before, but I’m saying it again: observability is not a synonym for monitoring, and there are no three pillars. The pillars are bullshit.

We recently sponsored our partner CloudBees’ conference DevOps World & JenkinsWorld in San Francisco and our message “Observe how Customers Experience Your Build” resonated well with the folks we met. Release engineers are critical to the continuous delivery cycle and knowing the right time to ship is important for internal business stakeholders but more importantly end-user customers and especially if it’s a significant release.

Are you starting out on your journey toward observability? Do you have a mandate from management, or are you a lone warrior in the matrix? From your starting point, how will you make the right decisions about how to implement changes to your logging and aim for the right path through the various choices in front of you?

Greetings, fellow o11ynaut! You may recall a post we shared here about two months ago that told tales of the themes we felt best represented our recent release of the Framework for an Obsersvability Maturity Model. Well, the o11y maturity model was once again the primary topic and focus of Honeycomb’s most recent Observability Roundtable event held in San Francisco in mid August.