According to the Uptime Institute’s 2022 Outage Analysis report, one out of every five companies has experienced a “serious” or “severe” incident over the past three years—a percentage that’s increasing. Those incidents are expensive: over 60% cost more than $100,000, while 15% set their companies back close to $1 million.
The customer success department at Honeycomb features a number of different roles dedicated to helping our customers succeed in every step of their observability journey. The work we do ranges from support engineers who provide timely assistance to customers, to customer architects who dive deep into the technical stuff, to product training who educate folks on features old and new.
Core Web Vitals (CWV) are Google's preferred metrics for measuring the quality of the user experience for browser web apps. Currently, Core Web Vitals measure loading performance, interactivity, and visual stability. These are the main indicators of what a user’s experience will be while using a web page.
When the Gartner Magic Quadrant Report came out in 2022, we did the professional equivalent of a spit take, then cheered wildly. NOT ONLY did they include observability for the first time ever in their newly revamped 2022 Magic Quadrant for APM & Observability, but they also put us in the Leader Quadrant—our debut appearance!
Honeycomb has the ability to receive events from applications. These events can take the shape of Honeycomb wide events, OpenTelemetry trace spans, and OpenTelemetry metrics. Because Honeycomb’s backend is very flexible, these OpenTelemetry signals fit in just fine—but sometimes, they have a few quirks. Let’s dive into using metrics the Honeycomb way and cover a few optimizations.
In technical support, ensuring customer satisfaction and quickly resolving issues are of utmost importance. At Honeycomb, we embrace a comprehensive approach by using our own platform—not only for engineering purposes, but to also empower our support team. By utilizing Honeycomb, our support engineers can monitor, troubleshoot, and investigate customer issues with great efficiency.
Insightful proof-of-concepts with a tool can be difficult to undertake due to the demands on valuable resources: time, energy, and people. With a task as grand as observability, how could one truly test if Honeycomb and OpenTelemetry are right for their organization and meet their requirements? For this thought experiment, here’s a comprehensive description of the ideal product evaluation over the course of four weeks, given unlimited resources.
People seem to struggle with the idea that there are no repeat incidents. It is very easy and natural to see two distinct outages, with nearly identical failure modes, impacting the same components, and with no significant action items as repeat incidents. However, when we look at the responses and their variations, we can find key distinctions that shows the incidents as related, but not identical.
OpenTelemetry and Beelines were designed with assumptions about the types of traffic that most users would trace.
At Honeycomb, we are all about observability. In the past, we have proposed observability-driven development as a way to maximize your observability and supercharge your development process. But I have a problem with the terminology, and it is: I don’t want observability to drive your development.
