Honeycomb Enterprise Reviews

My main use cases for Honeycomb Enterprise are extensive tracing and monitoring of my current systems with microservices.

I assess the high impact of high cardinality data analysis on my application performance optimization by using dashboards that have trends for basic metrics such as latency, number of panics, and how our clients are calling our microservice. We see if there is any change in those patterns over time, and if anything seems to dip or rise in an unusual manner at a certain time, we dig into that. We can add more details in those traces to get a better viewpoint, which allows us to dig deeper into what we can improve in the system or what we can ask the clients to change in their approach when calling our system.

Honeycomb Enterprise's structured tracing has helped in understanding complex user interactions by allowing us to set the tracing to see the request bodies that the clients are sending, how long the responses are taking in our system, and how they are sending it back to the user. We get to see the different permutations of what a client can request from us, which helps us gauge real-time usage of how the client is using our system and how the users are manipulating their requests to our system.

I have utilized BubbleUp.

The best features of Honeycomb Enterprise include having a dashboard with set dedicated spans and viewpoints to be able to see the error spans or healthy spans that you want set up, and then being able to dig within individual spans and having the ability to set attributes and errors that are groupable to be able to see trends and patterns.

Honeycomb Enterprise has helped my team identify performance anomalies by allowing us to set dashboards that look for errors and then the errors pop up easily in the dashboard. We can sync that to alerting, which sends us a message in Slack or our phones as needed, so it helps with production support or being on call.

The benefits I have seen from using Honeycomb Enterprise include that it has been excellent to be able to see it as a replacement for logging for us where we stop going into AWS CloudWatch logs and it is much easier and faster to go into Honeycomb Enterprise and look at the tracing that happens there.

I think Honeycomb Enterprise can be improved by having a more concrete MCP connection with Cloud Code to facilitate natural language conversations with Cloud Code to analyze metrics and tracing.

I have been using Honeycomb Enterprise for about three to three and a half years.

I am aware that there is rarely any downtime with Honeycomb Enterprise, so I do not think there are stability issues.

Honeycomb Enterprise scales best when all the products in the company use it because it allows tracing outside of individual products to see how they interact. Scaling was tricky as the pricing did not accommodate the scale initially as things grew, and throttling is expected based on the pricing models, but the biggest pain point was management or budgeting having to argue on why this was useful to upgrade to the newest pricing.

When I was looking at Honeycomb Enterprise support with Go Lambdas, it was a little tricky to find someone who could help me answer the question. I even went to the Slack group for Honeycomb Enterprise, and it was a little tricky to get a straight answer. I had to nudge them a couple of times to get a short response that it does not work.

I would rate the customer service and technical support from Honeycomb Enterprise a six.

Before choosing Honeycomb Enterprise, my company evaluated other solutions such as AWS metrics, where we were considering jumping into creating everything in AWS metrics, but it involved a lot of overhead and ramping up, and things were a little confusing. We also considered Grafana, but many people did not have a good experience with it, and Datadog as well, but I am not sure why we did not go with Datadog. We ended up going with Honeycomb Enterprise because of the pricing at first, and once we experienced how well things fit together and how the dashboards were set up, we ended up going with full price.

Before adopting Honeycomb Enterprise, my company used just AWS CloudWatch logs.

The initial setup for Honeycomb Enterprise was similar to the same amount of effort as adding logs with AWS CloudWatch in the codebases. Adding the tracing and knowing what attributes you want to be viewable in your tracing was a learning curve, but creating the dashboards was pretty easy. We are still at a learning curve on how we want to strategize adding attributes to our tracing, but it has been pretty easy going so far.

We are using Honeycomb Enterprise in the cloud because the microservice is deployed in the cloud, and we assume we are using Honeycomb Enterprise in the cloud; we are not hosting Honeycomb Enterprise anywhere.

The biggest return on investment with Honeycomb Enterprise is being able to find, if I am doing production support and something goes wrong, the exact scenario or the exact request and response and the details of that really quickly. I have more detail than I would get from CloudWatch logs, and I can debug and find what happened twice as fast as I would if I dug through AWS CloudWatch.

My experience with the pricing, setup cost, and licensing of Honeycomb Enterprise has been that the setup is a big ramp up to get the codebase connected to the system, but once that is set up, then it is pretty easy. There is a lack of Lambda functionality with Go that does not exist with Honeycomb Enterprise, which is a pain when a lot of our code has that. In terms of pricing, it was a little challenging to get the company to commit to the full pricing of Enterprise, but once we got there it was nice. Before that, we had to sample a lot of tracing, so we hit limits and got throttled a lot.

We also considered Grafana, but many people did not have a good experience with it, and Datadog as well, but I am not sure why we did not go with Datadog.

My advice for companies considering Honeycomb Enterprise is to wonder if there is a free tier; I think there was a free tier that we tried, and I recommend it as a good monitoring tool. Even though the setup might be a little tricky for someone unfamiliar with it at first, it is worth giving it a try. If it does not fit, you can always take it out and replace it with something else, but that would be pretty unlikely if you find it useful. I would rate this product an overall eight point five.

My main use case for Honeycomb Enterprise is application observability and troubleshooting distributed systems, where I analyze traces, investigate latency and errors, understand service dependencies, and identify performance bottlenecks. Its high cardinality views help me narrow down issues quickly and understand what is happening across different services, making production debugging more efficient.

One specific example of how I've used Honeycomb Enterprise to solve a problem is when troubleshooting a slow API in a distributed application. I examined traces across multiple services and identified where the latency was occurring, which helped narrow the issue down to a slower database call rather than the API itself. This made troubleshooting faster and helped my team focus on the actual bottleneck instead of investigating every service individually.

The best features that Honeycomb Enterprise offers include distributed tracing, high cardinality querying, real-time observability, service dependency analysis, trigger-based alerts, and collaborative debugging.

The feature I find myself using the most is high cardinality querying combined with distributed tracing, as it helps me pinpoint the root cause of production issues much faster.

By using Honeycomb Enterprise, I have gained a crystal clear idea of the infrastructure that is behind our applications, also improving my application observability and troubleshooting process. It makes it easier for me to identify performance bottlenecks, trace errors across distributed services, and investigate production issues, reducing manual debugging effort, improving collaboration between the development and infrastructure teams, and helping us make faster and more informed decisions.

There is less manual effort and faster resolution time, with the biggest improvement being faster troubleshooting and reduced manual efforts. Instead of checking multiple services and logs individually, I use distributed traces to narrow down the source of an issue, helping the team identify bottlenecks more quickly and reducing investigation time. While I don't have verified percentage-based metrics, the improvement in debugging efficiency and incidents visibility has been valuable.

Honeycomb Enterprise is already good, and I would like to see more out-of-the-box integrations, such as simpler dashboards, customization, and more flexible alert configurations. Improvements in query performance for very large datasets and clear cost and usage visibility will also make the platform even more useful.

I have been using Honeycomb Enterprise for the last six to seven months.

Honeycomb Enterprise is stable.

The scalability is also good, providing me access to the platform whenever needed. It offers good scalability for distributed applications and growing telemetry volumes, handling high cardinality events and traces across multiple services, making it useful as application workloads grow. I particularly appreciate that teams can expand observability without managing the underlying storage and infrastructure. However, data volume retention requirements and usage costs should be monitored as the environment scales.

The customer support is good, but we did not get a chance to connect with them.

We were using different types of solutions, relying more on traditional logging and monitoring tools such as CloudWatch and basic log analysis. We considered Honeycomb Enterprise because we needed deeper distributed tracing, high cardinality queries, and better visibility across services, making root cause analysis more efficient, especially when troubleshooting complex application issues.

The setup process is easy with no significant challenges. We start by creating a Honeycomb Enterprise environment, configuring API keys, and instrumenting the application using OpenTelemetry. Then, we configure telemetry collection, define datasets, and set up dashboards and alerts. Once the data starts flowing, I validate traces and monitor application performance. The main effort is usually in instrumentation and deciding which telemetry data is most useful to collect.

The main return on investment is operational efficiency with Honeycomb Enterprise helping me reduce manual troubleshooting by making it easier to identify root causes across distributed services. It helps engineers spend less time investigating logs and more time resolving issues. While I don't have verified financial figures or exact percentages, the visibility provided offers clear operational value.

In terms of pricing, I think the pricing is minimal. The main consideration regarding pricing is data volume and usage, and the setup is relatively straightforward.

Before moving to Honeycomb Enterprise, we previously used AWS CloudWatch and traditional log monitoring tools, considering Honeycomb Enterprise for its advanced distributed tracing, high cardinality querying, and better visibility across microservices. It makes root cause analysis faster and simplifies troubleshooting complex production issues.

I would rate Honeycomb Enterprise an eight out of ten.

I chose eight out of ten because Honeycomb Enterprise provides strong observability, powerful distributed tracing, and effective debugging capabilities, helping teams identify performance bottlenecks and troubleshoot production issues faster.

Regarding governance and security, I believe they are important when using AI for application observability. Data privacy, access controls, and clear audit trails should be maintained, especially when telemetry may contain sensitive information. AI-generated insights should be transparent and validated by engineers before taking action, with human oversight and proper data handling policies being essential for building trust in the platform.

In terms of accuracy and reliability, Honeycomb Enterprise's AI-driven insights can be useful for identifying unusual patterns, investigating errors, and understanding performance issues. I find the output most valuable when it is supported by actual traces and telemetry data, and I will still validate AI-generated recommendations before making production changes. Accuracy, consistency, and explainability are important for reliable troubleshooting.

Currently, I am using Honeycomb Enterprise in a public cloud as a SaaS-based product, where application telemetry including traces, events, and performance data is sent to Honeycomb Enterprise through instrumentation and OpenTelemetry. This allows my teams to monitor distributed applications without managing the observability infrastructure themselves.

The advice I would like to give is to recommend starting with OpenTelemetry instrumentation and identifying the most critical application workflows to monitor. Make sure to evaluate distributed tracing, high cardinality during alerting, and integration with your existing tools. Start with a small proof of concept, monitor telemetry costs, and gradually expand coverage. The biggest value comes from using the data to identify root causes rather than simply collecting more logs.

My primary use case for Honeycomb Enterprise is troubleshooting production applications and distributed services using the observability data, particularly when a normal log search is not enough to explain what is happening.

A specific example where Honeycomb Enterprise helped me troubleshoot is in investigating a slow or failed API request, where the request goes from client to load balancer, then API gateway, then service A, service B, and finally a database in a multi-layer application.

I am using Honeycomb Enterprise in this way only.

Some of the best features Honeycomb Enterprise offers include distributed tracing, which is probably the most important feature for my use case, and it helped me answer where the request spent its time.

Honeycomb Enterprise has positively impacted my organization by improving the way I understand production problems and significantly reducing the time required to do so. I estimate that I spend around 40% less time troubleshooting now compared to before using Honeycomb Enterprise.

The learning curve for things such as traces, spans, high-cardinality data, and advanced queries is an area where Honeycomb Enterprise can be improved.

I would rate Honeycomb Enterprise around 8.5 out of 10 because being able to investigate a specific production request and understand what happened across a distributed system provides a very different value from simply watching CPU, memory, and uptime dashboards.

I have been using Honeycomb Enterprise for around one and a half years.

Honeycomb Enterprise is stable.

Honeycomb Enterprise is highly scalable.

The customer support for Honeycomb Enterprise is good.

I would rate the customer support for Honeycomb Enterprise nine out of 10.

I have not used any solution before this.

I have mentioned several things that need improvement for Honeycomb Enterprise.

I did not purchase Honeycomb Enterprise through the AWS Marketplace.

I have seen a return on investment with Honeycomb Enterprise, as I mentioned, with 40% time saved in troubleshooting.

My experience with pricing, setup cost, and licensing for Honeycomb Enterprise is that this is an area I evaluate carefully due to potentially complicated observability pricing as the amount of telemetry grows with application traffic.

Before choosing Honeycomb Enterprise, I evaluated other options such as traditional ones like CloudWatch, Grafana, Prometheus, New Relic, and Datadog.

Some of the best features Honeycomb Enterprise offers include distributed tracing, which is probably the most important feature for my use case, and it helped me answer where the request spent its time.

If production troubleshooting is an issue for you, Honeycomb Enterprise is the only solution and is a very good one. I would rate this review 8.5 out of 10.

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.

Honeycomb Enterprise serves as the main observability, distributed tracing, and troubleshooting solution for microservices in my project.

A specific example of how I have used Honeycomb Enterprise in a real scenario involved an API that was taking longer than expected. In my day-to-day work, apart from troubleshooting, I also use Honeycomb Enterprise to monitor application performance after deployments and check whether response times or error rates have changed.

Honeycomb Enterprise has positively impacted my organization by enabling troubleshooting and production monitoring in a more efficient way.

Honeycomb Enterprise has helped make troubleshooting more efficient by reducing the time spent manually checking logs across multiple services.

The best features Honeycomb Enterprise offers are the distributed tracking, flexible querying, and the ability to analyze high-cardinality data.

Flexible querying in Honeycomb Enterprise helps me investigate issues without being limited to predefined dashboards.

Another thing I appreciate about Honeycomb Enterprise is that I can connect the dots between different services instead of looking at each solution in isolation.

Honeycomb Enterprise can be easier to learn, especially for those who are not familiar with distributed tracing and high-cardinality data.

I have been using Honeycomb Enterprise for about two years.

Honeycomb Enterprise is stable and provides useful visibility into application behavior, helping my team investigate performance issues across services.

Honeycomb Enterprise offers good scalability for monitoring applications with multiple services and large volumes of telemetry data.

The customer support for Honeycomb Enterprise is good. I would rate the customer support seven out of ten.

I definitely see a return on investment in terms of time saved with Honeycomb Enterprise.

Regarding pricing, setup cost, and licensing, these are not much of a concern because as the volume of telemetry data increases, pricing will be a consideration. However, the initial setup is fairly straightforward.

I would rate Honeycomb Enterprise seven out of ten. The reason I gave this rating is because it provides strong distributed tracing and useful query capability, but the learning curve is steep for new users.

Regarding Honeycomb Enterprise's AI capabilities, I find it a useful foundation for troubleshooting, but I would want clear controls around data access and user permissions. Honeycomb Enterprise's AI output is sometimes useful but may not always meet my expectations for accuracy and reliability.

I find Honeycomb Enterprise's AI output accurate. I find Honeycomb Enterprise useful for understanding issues across services, but I treat AI analysis as a recommendation rather than the final answer.

My advice would be to clearly identify your observability needs before adopting Honeycomb Enterprise and ensure the team is comfortable with distributed tracing and OpenTelemetry.

Although Grit is a tool code code migration and management of technical debt for large chunks of work, we reviewed Grit from the use case of assisting in faster remediation of vulnerable libraries. We examined 3 areas and how we could use the synergy of Grit.io along with Snyk.io that helps overcome Snyk's limitations:

1. Deep scanning and reachability analysis

2. Management of auto-generated Pull Requests (PRs)

3. Reduction of false positives

I'm connected and had interactions with the founder Mr. Morgante Pell, while I designed a comprehensive synergistic solution, and I wrote a 35+ page technical paper on this topic.

Large organizations with hundreds of development teams and tens of thousands of code repositories face challenges in efficiently identifying and remediating potential vulnerabilities within third-party libraries across numerous projects. Manual scanning and updating is time-consuming, error-prone, and can lead to delays in addressing security risks.

While Grit.io is not primarily a vulnerability scanner, its pattern-matching and code transformation capabilities can be adapted for mass identification and remediation of vulnerable libraries.

For each of these 3 areas listed above, we examined how Grit.io's unique features can complement Snyk.io's capabilities, resulting in a more robust and efficient security scanning process. We realize This synergistic approach addresses the limitations of relying solely on Snyk.io, resulting in improved code security and reduced risk of overlooking critical vulnerabilities.

The limitations of security scanning tools like Snyk.io represent real challenges faced by development teams on a daily basis. These limitations can lead to:

- Missed vulnerabilities in complex code structures

- Overwhelming numbers of auto-generated PRs, causing developer fatigue

- High rates of false positives, leading to wasted time and resources

We considered implementing Grit into our pipelines to address these specific scenarios for code security, though Grit isn't a security tool:

- Custom Rules and Pattern Creation

- Remediation Pattern Creation

- Automated Code Updates

- Custom Pattern Recognition

- Pull Request Generation

- and others

1. Grit.io's flexibility allows for custom rules and patterns to identify vulnerable libraries, extending its use beyond traditional refactoring tasks.

2. Automated pull requests streamline the remediation process, facilitating efficient mass updates across multiple repositories.

3. While not a replacement for dedicated security tools, Grit.io can be a valuable addition to a large organization's security toolkit for vulnerability identification and remediation.

4. The approach offers significant benefits in terms of efficiency, consistency, and proactive security management, particularly valuable for organizations with large, distributed development teams.

I asked very specific questions to Mr. Pell about consideration of code security scenarios in pattern design and rules, specifically that tuned with OWASP Top 10. I believe addition of code security focus can be a value-add, though the way Grit architecture is designed and how it works, it is and may not become an alternative choice of code security solutions. Rather, it must be treated as a powerful supplementary tool that augments the existing code security solutions (such as Snyk or Checkmarx) in a DevSecOps or Secure DevOps environment.

Anyone interested in learning more on this front or have queries, can get in touch with me for a consulting.

Our internal comprehensive evaluation of Grit spans over 6 months to a year since our client organization considered Grit under the Accelerator program of promising AI startups back in Sep 2023. Different phases of the implementation have been conducted by various development architects spanning several scenarios. Our scenario was very specific to how Grit's AI-powered capabilities could be leveraged on code security remediations for a large tech ecosystem.

My main use case for Honeycomb Enterprise is alerting and full stack tracing. I use Honeycomb Enterprise for tracking our traces from the front end all the way to our back end in Kotlin, and through Kafka and into Elastic. This helps us to spot any bottlenecks and see where errors occurred in our data processing pipeline.

We primarily use Honeycomb Enterprise to power our alerting, so we get alerts based on throughput, based on spikes, anomalies, and any error rates in each service. The best features Honeycomb Enterprise offers are alerting, which is mainly what we use it for.

Visualization is fine for me, although our dashboards are a bit cluttered. Primarily, the alerts are the most useful thing. The querying is good, although sometimes a bit messy. I would appreciate a better way to store my queries, perhaps with some auto-fill functionality. The alerts are the best feature.

Honeycomb Enterprise has positively impacted our organization by providing live alerts. We have been able to get alerts when something may pop up and see any issues in the system. We get alerts into Slack, and they work great. We see a lot of metrics go through into Slack, and they are really useful for keeping our team focused on only seeing one place to see alerts.

Honeycomb Enterprise can be improved by having a cleaner dashboard and a nicer way to search between insights.

I have been using Honeycomb Enterprise for one and a half years.

I do not have the metrics for a return on investment, but it has been very useful.

Having those alerts and metrics in Slack helps with our SLAs. If we ever have downtime in a service, we can get back to it straight away. I rate Honeycomb Enterprise a seven out of ten because I feel a lot of the journeys could be made cleaner. Some of the dashboards and the insights could be a bit more well-refined. For example, Grafana has a lot better visualization tools, but it needs to be a bit more involved.

Honeycomb Enterprise is deployed in our organization in a public cloud and is hosted by Honeycomb, who is the provider.

My experience with pricing, setup cost, and licensing is that the number of samples would be good. The number of events, really, so we can pay less. I do not have the metrics for a return on investment, but it has been very useful. It is quite expensive, but I think we get value out of it. My overall rating for Honeycomb Enterprise is seven out of ten.

We were building a product for one of the biggest wealth management platforms in the world, an American wealth management platform. For them, it is really important for the product to be reliable and for them to set up KPIs, especially for vendors like us who worked for them.

The debugging process usually involved Splunk Cloud or Honeycomb Enterprise traces. Whenever I was looking at an issue, I probably went through the traces because it was a microservice architecture. Sometimes it really helped to understand the call chain. For example, if there were 10 microservices calling each other in some sort of order, being able to visualize that and look through that was pretty useful.

I would say all of these three are pretty good features of Honeycomb Enterprise.

Honeycomb Enterprise is super useful if you think before this paradigm shift, when it was really important for humans to be able to see things visualized. For me to better understand in this very complex microservice architecture what's going on, Honeycomb Enterprise really helped with that through its good UI. However, the reason it's only five is because it's lagging behind in terms of AI-compatible features.

The major thing that's missing from Honeycomb Enterprise is AI compatibility. As far as I know, it's not really a text-based or code-based tool. It's more of a UI right now, which before this paradigm shift where everyone is using AI agents to work, was pretty useful. However, after this paradigm shift, I think it's really important for a tool like this to be AI-friendly. Honeycomb Enterprise is really lagging behind in this area, and I don't know how they could manage that.

For us it was sometimes pretty slow using Honeycomb Enterprise. I don't know if that can be improved. Although we might use the paid solution or self-host it somewhere because of privacy concerns. Maybe that's not Honeycomb Enterprise's fault. However, the main thing is that I think everything should very hard aim for the direction of being AI compatible because every engineer, or most engineers now use AI to code. If something is not easy to work with AI agents, that will stay in the past.

I used Honeycomb Enterprise at my previous job for around one to one and a half years.

Honeycomb Enterprise is stable.

It's very scalable since we used it for a really big organization and it worked.

If it's a big company, I understand using Honeycomb Enterprise. If it's a small company, I would suggest using some sort of open-source solution or something that is code-based and is easier to use with AI.

The solution is mainly used for stack observability. It observes service behavior or any kind of failure that may be happening. The tool is also related to research. My company is working more on this, but I have been working on my SLOs and defining SLOs for the last seven months.

The solution's most valuable features are the queries for the OpenTelemetry events and all the tracing. The solution is very easy to use, and the dashboard is very intuitive.

We faced some OpenTelemetry metrics lost between the communication from the service and the Honeycomb.io. I can't say if this is a Honeycomb.io issue or if there are some limitations in OpenTelemetry.

Alerts are very helpful in Honeycomb.io, but we don't usually merge because we can compare queries with queries for making alerts. We can make alerts based on static numbers, which may block us from building alerts that could be generic enough or could be serviced.

I have been using Honeycomb.io for two years.

We’ve never had any issues with the solution’s stability.

Honeycomb.io is a scalable solution. The service is very resilient and can handle a lot of data. The quantity of data Honeycomb.io can parse and use to create charts is really good. More than 100 users are using the solution in our tech team.

I rate the solution’s scalability an eight or nine out of ten.

The solution's initial setup is easy. I think the hardest part is to understand OpenTelemetry in general.

We set up Honeycomb.io on all the services so that we can have all the set traces of the communication between all the services inside the company. This helps us understand where it could be failing, which in turn helps with failures and observability.

When we are not thinking about one specific failure but a major one, we can create queries for statistics views like the P99 or P95 behaviors. That's very helpful. I would recommend the solution to other users because it is very helpful.

Overall, I rate the solution a nine out of ten.

There aren't any specific use cases for the solution as such. In our company, we use the solution for SLA and SLO-related work.

Honeycomb.io facilitates the identification of service downtime by integrating with our logging endpoint in Splunk. We log the endpoint in Splunk, and Honeycomb.io scrapes those logs. Honeycomb.io employs a different set of queries to alert the application team whenever it is unable to scrape the logs. This notification informs the team that the app is down.

There aren't currently many features we are using in the solution. The features that we use in the solution are to improve the functioning of our organization.

The process of log scraping gets delayed on Honeycomb.io. At times, it gives false alerts to the application team.

It would be good if Honeycomb.io could integrate with third-party tools or paid services, which can make it easy for us to alert our teams more frequently.

I have been using Honeycomb.io for six months. Also, I don't remember the version of the solution I am using.

Stability-wise, I rate the solution an eight out of ten.

Scalability-wise, I rate the solution a seven out of ten.

We don't have any plans in our company to increase the usage of the solution.

The solution's technical support team is good. We have received a few hours of support directly from the support team. Also, we used to have KT sessions organized by Honeycomb.io, during which we used to get our queries addressed while attempting to get familiar with the tool.

The solution's initial setup process was straightforward since we were getting enough support from Honeycomb.io's team. The solution is deployed on the cloud.

Specifically, I would suggest application teams use Honeycomb.io since it is a good tool. Also, it can be helpful for members of applications teams to identify downtimes and SLO-related issues. Overall, I rate the tool an eight out of ten.