Honeycomb Enterprise

My main use case for Honeycomb Enterprise is application observability and troubleshooting distributed applications. When it comes to scalability and handling applications, managing microservice-architected applications is quite difficult. There should be a trace of each log and observability point. Honeycomb Enterprise helps us follow requests across multiple different services and investigate latency and errors, understanding where the problem originates, which ordinary logs and infrastructure generally do not provide with sufficient context.

For example, if I consider one API that becomes very slow after a software release, I find that the infrastructure metrics show normal CPU and memory usage, but what our customers experience is delay in getting back the response. Honeycomb Enterprise helps me examine the request trace across the API, the downstream services, and the database calls to identify the slow operation and investigate the root cause.

Honeycomb Enterprise has positively impacted my organization by reducing the time engineers spend investigating production incidents and reducing customer resolution time. We reduce troubleshooting time for complex issues by 40 to 50%. These improvements are very important when handling things in production.

I measure that 40 to 50% reduction in resolution time by estimating improvements on issues that previously took one to two hours to isolate, which can often be narrowed down to 20 to 30 minutes using distributed tracing and BubbleUp. The end-to-end tracing follows requests across multiple microservices instead of manually correlating logs from each service. Using high-cardinality queries, we filter request ID, endpoint, service, and other attributes to isolate affected requests and perform faster root cause analysis, where engineers could narrow down the problematic service or database call, significantly reducing investigation time. Previously, investigations taking two hours can now be completed in 30 minutes to one hour, resulting in a 50% reduction.

One of the best features I appreciate most about Honeycomb Enterprise is the distributed tracing capability, because it is one of the most valuable capabilities, helping me understand how an individual request passes through different services and identify where time is being spent, allowing me to easily narrow down the source of an error. The high-cardinality queries are also very useful because I can investigate specific users, requests, services, or error conditions without depending entirely on predefined dashboards.

The high-cardinality analytic tools help me in my day-to-day work by allowing me to investigate issues at a much more granular level. I considered an issue particularly with an API request, where it became slow and customers experienced delayed response. We could filter the telemetry using attributes such as the request ID, user ID, endpoint, service name, and deployment versions to identify the specific request or service causing the issue. Instead of relying only on a general dashboard to search through logs, we could drill into distributed traces and identify where latency or errors occurred. This helps speed up root cause analysis, reduce troubleshooting effort, and improve incident resolution.

I suggest a few areas where Honeycomb Enterprise could improve. One is better onboarding for OpenTelemetry and more customizable dashboards, clearer cost forecasting, and stronger integrations with DevOps and incident management workflows. These improvements would make the platform easier to adopt while preserving its strength in detailed production investigations.

I have been using Honeycomb Enterprise for the past two years.

I rate Honeycomb Enterprise an eight overall.

I rate it an eight because the main strengths are distributed tracing, flexible investigation, and the potential to reduce debugging time. The deductions reflect the learning curve. I deduct two points because dashboard customization has limitations, onboarding for OpenTelemetry needs improvement, and clear cost forecasting is required. Additionally, I would appreciate stronger integration with DevOps and other incident management workflows.

Regarding Honeycomb Enterprise's governance and security, it is very important for an organization because governance should cover access controls, SSO (single sign-on) operations, role-based permissions, telemetry retention, and the handling of sensitive attributes. Honeycomb offers enterprise-oriented access and security capabilities, but the exact controls depend on the plan and configurations. They are well-versed in security protocols, but we have to ensure that we are not sending secrets or unnecessary personal data in traces and verify the organization's compliance requirements before onboarding production telemetry.

Regarding Honeycomb Enterprise's accuracy and reliability of output, the platform provides useful request-level context for troubleshooting when telemetry is correctly instrumented and collected. Its findings have really helped my engineers and me identify bottlenecks. However, data still needs interpretation in context and verification against application behavior. Missing instrumentation, sampling, and incomplete attributes can limit investigation, but overall, Honeycomb Enterprise is accurate and reliable, cutting down 50 to 60% of the troubleshooting time.

When advising others looking into using Honeycomb Enterprise, I recommend that when starting with critical applications or microservices, troubleshooting production issues is very important and time-consuming. There will be a number of services, and tracing in and out of each service is very challenging. I suggest integrating with OpenTelemetry, instrumenting important services and APIs, and using distributed tracing and high-cardinality queries to understand where requests are slowing down or failing. Others can assess their requirements and research the features they seek. Training is involved for the engineering team on tracers and queries capabilities, which requires considerable effort, and saving this effort is something I highlight as vital. My rating for this product is eight out of ten.

I joined Smarsh in 2023 as a software engineer, and from that point until last year, we were using Honeycomb Enterprise. Recently, we migrated to a different service.

I have used Honeycomb Enterprise in the past 12 months, and it was very good. We used it mainly for tracing and observability. By observability, I mean we did not use it primarily for metrics and other features. The main goal was to use it for tracing, traceability, and debugging errors.

When comparing Honeycomb Enterprise to DataDog, the current service we are using has the best features. However, I never explored metrics completely with Honeycomb Enterprise. With tracing, Honeycomb Enterprise is the cheaper and best service for tracing and traceability compared to DataDog. I did not explore Honeycomb Enterprise to that extent for metrics.

The best feature Honeycomb Enterprise provides is the sampling. Whenever we publish traces, out of 1000 traces, it samples the best-rate traces, and it has the capability to implement a graph from the tracing that we have published. This is the most impressive feature I have seen. From error logs or whatever we publish, we can easily visualize those traces in graphs and identify the number of occurrences that have happened for a particular trace, error log, or observability failure in a service. The main features I highlight are the graph feature and sampling.

With structured tracing, it helps us understand complex user interactions. Since we are dealing with billions of traces every day from 1000 or 2000 services running daily, with each service emitting nearly more than 10,000 traces, identifying which service has errored out in a particular environment or region and at what time was critical. Honeycomb Enterprise is the best solution for this. It performs sampling based on error rates and provides us the data to visualize. When we search for any error logs or what happened with a service at a particular moment, it is very easy to search any traces and identify the root cause and fix those issues. Using Honeycomb Enterprise as a tracing service made it very quick to identify and fix issues.

When assessing the impact of high cardinality data analysis on application performance optimization, our company deals with multiple documents, and each data point deals with multiple documents, multiple IDs, and multiple unique records. Each record has a high cardinality field. If we go with any observability services like DataDog, Grafana, or other services, publishing high cardinality fields would be difficult for the system and would cost more. Honeycomb Enterprise supports high cardinality fields in a very easy way, and the pricing is very reasonable. We used to publish even high cardinality fields for tracing, but not for metrics.

The areas for improvement with Honeycomb Enterprise lie in the query UI, which could be improved to a more current standard. The older query interface shows facets, and if I need to select an option, I must drop down through multiple choices, which could be improved substantially, and we could even adopt AI tooling. While performing sampling, I do not know internally how Honeycomb Enterprise executes the sampling. At the very least, while querying, as an external user or someone who does not know how the code works for their service, the experience could be better. Let me illustrate: I know my service code and how it works, but another team member may not completely understand how the code works. Even if they search in Honeycomb Enterprise, they need to understand what traces we are publishing. If AI implementation were added, it could suggest queries or, when I type something like "I want these traces present within this time in this service," it should frame the query automatically. I want that feature to come to Honeycomb Enterprise. I do not know whether it exists currently because we stopped using Honeycomb Enterprise almost five or six months ago.

For stability, I can rate it a nine or ten. I have never seen Honeycomb Enterprise go down.

Regarding scalability, I have never seen any lagging in the service while using it, and I have never seen Honeycomb Enterprise go down. Since it is a managed service, I agree that it was scalable. I would rate this a nine as well.

For technical support, I never had to make a call for any support. Our concern was not to maintain Honeycomb Enterprise. As an engineer, we simply utilized that tool. We were never concerned about how it connects, what it does, what the storage was, or what billing had been done for it.

If comparing Honeycomb Enterprise to DataDog, the current service we are using has the best features. However, I never explored metrics completely with Honeycomb Enterprise. With tracing, Honeycomb Enterprise is the cheaper and best service for tracing and traceability compared to DataDog. I did not explore Honeycomb Enterprise to that extent for metrics.

Since Honeycomb Enterprise is not self-hosted and is a managed service, we never maintained anything.

We used Honeycomb Enterprise mainly for tracing and observability. By observability, I mean we did not use it primarily for metrics and other features. The main goal was to use it for tracing, traceability, and debugging errors.

I would recommend Honeycomb Enterprise based on cost evaluation. Companies considering purchasing it should discuss the features they want and partner with Honeycomb Enterprise. The decision is theirs, but as an end-user, I would recommend the UI interface, the interaction with the UI, and all the services that I have seen in Honeycomb Enterprise.

I am completely unaware of the pricing because we as engineers are not aware of the price. In every company, there is a pricing manager, COGS management team, and a fabric team. The fabric team handles all the pricing models and related matters. As an end developer, I am not certain what pricing was incurred by Smarsh for using this service. However, one thing I learned is that due to pricing considerations, Smarsh moved from Honeycomb Enterprise to another service.

I would rate this review an eight overall.

I have been using Honeycomb Enterprise for the past three years. My main use case has been troubleshooting and performing monitoring for Kubernetes-based applications and microservices.

Honeycomb Enterprise has had a very positive impact on our organization by reducing the time it takes to identify and resolve production issues. Instead of spending hours searching through logs across multiple Kubernetes services, we can quickly pinpoint the source of the problem using distributed tracing. This has really improved our mean time to resolution and reduced downtime while helping us deliver a more reliable experience for our users. It also gives the engineering team greater confidence when deploying a new release because we can validate performance and catch regressions much earlier.

When I observed a significantly increased response time after a new release to one of our microservices running on AKS, the infrastructure appeared healthy and the CPU and memory were normal, but users were reporting latency delays. Using Honeycomb Enterprise, I filtered traces for those affected services and compared slow requests against normal ones. The distributed trace showed that most of the latency was coming from a downstream API call rather than the application itself. By drilling into the trace attributes, I was able to identify that a specific endpoint was experiencing significantly high response time. After the deployment, I rolled back the change and confirmed the latency returned to normal, then fixed the issue before redeploying. Honeycomb Enterprise made it very easy for me to pinpoint the exact service and operation causing the slowdown, which reduced our troubleshooting time very significantly.

Beyond troubleshooting production issues, I have also used Honeycomb Enterprise proactively for monitoring and validating deployments. After a new release, I monitor key metrics such as request latencies, error rates, and throughput to ensure there are no regressions. I have also used it during root cause analysis by correlating traces across multiple Kubernetes services, which helped determine whether an issue originated in the application, the infrastructure, or an external dependency. The ability to query high-volume issues data and drill into specific requests has been specifically valuable for identifying all these issues and reducing troubleshooting time. Overall, it has become an important part of our observability workflow and helps solve incidents much faster.

Some of the best features for me include distributed tracing, which gives me end-to-end visibility into a request as it flows across multiple microservices, making troubleshooting faster. I really appreciate the ability to query high-level data without having to predefine dashboards or indexes. This means I can investigate issues from different angles even if I did not anticipate them beforehand. Another feature I use frequently is BubbleUp, which automatically highlights the differences between normal and problematic issues, making it easier to identify root cause. The integration with OpenTelemetry is a significant advantage because it allows us to collect standardized telemetry from our Kubernetes workflows and workloads without being locked into a proprietary instrumentation approach.

Overall, I have had a very good experience with Honeycomb Enterprise, but there are a few areas where it could be improved. I would like to see more out-of-the-box dashboards and templates for common Kubernetes and cloud-native workloads so that new users can get value more quickly. The learning curve can be steep, especially for engineers who are new to distributed tracing and observability concepts. Additionally, while the query capabilities are very powerful, there are times when specifying advanced query workflows could be improved to provide a better overall experience for troubleshooting and observability.

Beyond what I mentioned, there are a few other areas that could also be improved. I would like to see even deeper native integration with more DevOps and ITSM tools to make it easier to connect observability data directly into incident management and operational workflows. Regarding pricing, Honeycomb Enterprise delivers strong value, but as organizations scale and generate larger volumes of telemetry, cost can become a consideration. More flexible pricing options or cost optimization features for high-volume environments would be helpful. My support experience has been generally positive, but faster turnaround time for complex technical issues and more advanced implementation guides or best practices documentation would make onboarding and troubleshooting easier. These improvements would make an already strong observability platform even more accessible and scalable for enterprise teams.

I have been working in my current role for the past almost three years. In general, working as a technology engineer, I have been in the technology market for a span of ten good years.

I would rate the scalability as very good. As our Kubernetes environment and the number of microservices grew, Honeycomb Enterprise continued to handle the increased telemetry volumes without requiring major changes on our side because it is a managed SaaS platform. We were able to onboard additional services and workloads with minimal effort using OpenTelemetry. The main consideration is managing telemetry volume as your environment scales since more data can impact cost. As long as you have good instrumentation practices and data management policies, the platform scales very well for enterprise environments.

Overall, my experience with Honeycomb Enterprise customer support has been positive. The support team has been knowledgeable and responsive, especially when we had questions about instrumentation, OpenTelemetry integration, or troubleshooting complex observability issues. For standard questions, we usually receive helpful responses within a reasonable time frame. For more complex technical issues, resolutions sometimes take longer because they require deeper investigation, but the support team kept us informed throughout the process. I rate the support around 8 to 9 out of 10. The main area for improvement would be faster turnaround time for complex enterprise cases and more advanced technical documentation for edge case scenarios.

The organization was actually using a different solution before I came in. I do not know the reason why the organization changed, so I cannot provide more insight into that.

The pricing is reasonable for the value it provides, especially for organizations running large-scale microservices. The biggest consideration is that cost can increase as telemetry volume grows. It is important to have very good data management and retention policies in place. From a setup perspective, the initial implementation was straightforward since we use OpenTelemetry with our Kubernetes environment and the documentation made the onboarding process fairly smooth. The licensing was also relatively simple to manage. My only suggestion would be to offer more flexibility for organizations with rapidly growing telemetry volume or response spikes in usage. Overall, I am very satisfied with the setup experience and the licensing, and I felt the platform delivered good value for the investment.

We did not publish a formal KPI specifically for Honeycomb Enterprise. From my experience, I estimate our incident investigation time dropped by around 40 to 50 percent for complex microservice issues. Problems that would previously take one or two hours to isolate were often narrowed down to 20 to 30 minutes using distributed tracing or BubbleUp. This translates into faster incident resolution, less service disruption, and quick recovery during production issues. The biggest benefit was not just the time saving but being able to identify the root cause with much greater confidence instead of manually correlating logs from multiple services.

We did not calculate a formal ROI specifically for Honeycomb Enterprise, so I cannot give an exact financial figure. The biggest return has been in time saving and operational efficiency. Based on my experience, our troubleshooting time for complex production incidents improved by roughly 40 to 50 percent, with issues that previously took hours to isolate often being narrowed down to 20 to 30 minutes. This helps the organization reduce disruption and improve our mean time to resolution. We have not reduced headcount because of Honeycomb Enterprise. Instead, it allows our engineering team to spend less time firefighting and more time delivering new features and platform improvements. From that perspective, the productivity gains have provided a strong return on investment.

We looked at a few other observability platforms before settling on Honeycomb Enterprise, and the main ones were DataDog, Dynatrace, New Relic, Grafana, and Prometheus for metrics. Each of them had strengths, but Honeycomb Enterprise stood out for distributed tracing and high cardinality data, as well as the ability to perform ad hoc investigations without having to predefine dashboards or indexes. Since we run a Kubernetes-based microservice environment, that flexibility made troubleshooting much faster. We also appreciated its strong OpenTelemetry support, which fits well with our observability strategy. Ultimately, Honeycomb Enterprise gave us the best balance of deep troubleshooting capability and ease of investigating complex production issues.

I would say that Honeycomb Enterprise takes governance and security very seriously. I appreciate that it supports enterprise features such as role-based access control, SSO integration, and audit capabilities, which are important for controlling access to observability data. From an AI perspective, I see the AI features more as an assistant for integration rather than something making autonomous decisions, which is the right approach for production environments. I still want engineers to validate recommendations before taking actions. Overall, I would say the governance and security are strong, and I would always prefer to see continuous improvement around access control areas, data privacy options, and transparency into how AI generates insights and processes data, especially for organizations with very strict compliance requirements.

The AI capabilities are generally accurate and reliable, especially when used to assist with integration rather than replacing engineering judgment. The suggestions and insights usually surface patterns that I might not notice immediately. That being said, I do not treat AI output as my final answer. I always validate it against distributed traces, telemetry, and application logs before making production decisions. Overall, I rate the AI accuracy high for accelerating root cause analysis, but I still see it as a decision support tool rather than an autonomous troubleshooting solution.

My advice would be to invest time in planning an observability strategy before rolling it out and instrument your applications. I would also recommend instrumenting your applications with OpenTelemetry from the beginning and focusing on collecting meaningful telemetry instead of trying to capture everything. Start with your most critical service and build from there. I also recommend training the engineering team on distributed tracing and Honeycomb Enterprise query capability because that is where you will get the most value. Finally, monitor your telemetry volume and retention policy to keep costs under control as your environment grows. If you approach it that way, Honeycomb Enterprise becomes a very powerful tool for troubleshooting, performance optimization, and improving the reliability of your cloud-native applications. I rate this product a 9 out of 10 overall.