Operations | Monitoring | ITSM | DevOps | Cloud

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.

Does your organization have an on-call rotation? Several members of the Honeycomb engineering team recently hosted a live webcast about why they never feel alone when on-call at Honeycomb.

This guest post is from Evan Shaw, Lead Engineer at vendhq.com. GraphQL is a query language for APIs. It allows you to expose all your data through a single queryable graph. Compared to RESTful APIs, GraphQL brings greater flexibility in how your data is exposed, a more structured schema for type safety, and fewer round trips to your server for better latency. When we introduced a GraphQL at Vend, the feedback from our frontend engineers was clear: “This is a game-changer.”

“Nines don’t matter when users aren’t happy” is something you may have heard a time or two from folks here at Honeycomb. We often emphasize the fact that while your system can look healthy at a high level, deep down something is likely broken in ways that cause pain for users. If you are empowered to ask detailed questions about your services, you can find and understand these problems more easily.