Honeycomb Enterprise Reviews

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.

I am part of the performance engineering practice, and I lead the performance engineering practice at my current employer. We use Honeycomb Enterprise for tracing, which is application performance management in short. Our client has several APM tools such as Datadog, and in addition to Datadog, we only have the monitoring capacity of the counters. We do not have the agent-level monitoring which Honeycomb Enterprise is providing, where we can see the traces for each call being made by the software to trace where it is spending the time. For that gap, they have Honeycomb Enterprise in addition to Datadog. We use Honeycomb Enterprise for the same purpose, as Honeycomb hooks into our applications and tells us the traces where the request is spending the time.

We have Datadog here and often we get restrictions related to cardinality on Datadog because of their billing systems. They have limitations of cardinality, and that is the impact. That is how we can compare the impact.

Another thing I want to add here is that the team here had tried to use Honeycomb Enterprise earlier for tracing, but they faced issues. They could not get proper tracing with Honeycomb Enterprise at that time. That is what I have been given as feedback.

My main focus is on the tracing part. We have a microservices architecture with multiple microservices, and we want to see how when the request flows across multiple microservices, where the time gets spent.

We mostly look at the time the requests spend. Honeycomb Enterprise would capture a trace and span, and from there, we look at the time, the milliseconds or seconds that get spent at a particular request. That is what we look at and what we are interested in.

I did not get a chance to utilize the BubbleUp feature, and I think this is the most famous feature for SREs. We have not been able to utilize BubbleUp.

Dynatrace has this PurePath technology where they have the ability to give end-to-end tracing, which is a very robust feature. AppDynamics also has certain good features such as we could deploy that on our database systems and it would give an entire picture of our database, showing which application is creating how much load. From a pros perspective, Honeycomb Enterprise could be a better candidate with high cardinality; when there are too many unique values, Honeycomb Enterprise could be more beneficial there.

I have used better tools, I would say. I would not say that I prefer Honeycomb Enterprise as much. I have used Dynatrace, and I found it more comprehensive, and AppDynamics and other tools. These tools can also provide good information, but I find other tools better.

Most of the products, I would say, such as Dynatrace or AppDynamics or New Relic, are targeting this microservices market. I think Honeycomb Enterprise can have something very dedicated for microservices because there is an explosion in the migration from monolithic to microservices. If Honeycomb Enterprise can create a stable solution which is easy to use and which gives additional value and helps for faster debugging with microservices, they can certainly gain market share from others.

Tracing is already there. I just wish that these tools are a bit less cryptic. These tools sometimes get quite cryptic for new users. The less cryptic they can be made, that can help these tools. Another thing is that for microservices, when you have multiple microservices installed, that is also required. There are tools where you install on a single microservice, but then these microservices interact with multiple microservices. That kind of picture, I have seen that in AppDynamics; they do give a picture showing that a particular request which arrived here had interaction with these other third-party services or microservices and databases. That is what we need. That is what performance engineers and SREs need to see for each request, where it spent the entire time; how many other services or databases it interacted with and what took more or less time, and if there is a sequence, it should highlight that also. Was it parallel or if, for instance, a call to service A and then a call was made to a database, or a call to service A and a database were in parallel, that kind of information.

I have used Honeycomb Enterprise for around a year.

Another thing I want to add here is that the team here had tried to use Honeycomb Enterprise earlier for tracing, but they faced issues. They could not get proper tracing with Honeycomb Enterprise at that time. That is what I have been given as feedback. This was also one of the reasons the team is less interested in using Honeycomb Enterprise. Most recently, as far as I know, they started using an open-source tool now, Jaeger. They also brought in Jaeger because when I was using Honeycomb Enterprise, I got this feedback that they could not use Honeycomb Enterprise meaningfully in the team, although they had this license and everything. What I know is that it was crashing with the application. These tools, as they instrument into the application, they can sometimes lead to crashes. I had seen this with AppDynamics also, but that was for a different client. There, we could see AppDynamics did provide a fix for that. The team did follow up with AppDynamics. They had a wider setup of AppDynamics in the company, so they could not just get rid of that. A similar feedback I also got from the team that when they were trying to use Honeycomb Enterprise for tracing, it was causing issues.

As I said, there have been issues with Honeycomb Enterprise. The team had reported to me that at one point in time when they were trying to use Honeycomb Enterprise, they faced stability issues. It was interacting with the application and causing some crashes in the application.

I would rate the stability of Honeycomb Enterprise around five.

Frankly speaking, we did not use it at such a large scale here, so I cannot comment on that. The Datadog we use here is quite scalable. That is being used for at least eight thousand hosts. Given the cloud version and all, the scalability depends on our provider, the service provider who gave us the Honeycomb Enterprise license. That is something which is beyond my scope.

The setup sounds a bit complex. The overall setup at our client's end is really very complex because they have high security limitations, which makes it a bit difficult to use any of the tools.

When other organizations are evaluating their APM tools, I could name Honeycomb Enterprise as one of the APM tools, another addition. There are not that many APM tools, with the top ones being Dynatrace, AppDynamics, New Relic and a few others. I heard about Honeycomb Enterprise in my current project only; I did not hear about Honeycomb Enterprise before. Given the new technologies emerging, if Honeycomb Enterprise can provide better traceability and monitoring, they have a chance.

Another thing is that for microservices, when you have multiple microservices installed, that is also required. There are tools where you install on a single microservice, but then these microservices interact with multiple microservices. That kind of picture, I have seen that in AppDynamics; they do give a picture showing that a particular request which arrived here had interaction with these other third-party services or microservices and databases. That is what we need. My overall rating for Honeycomb Enterprise is five out of ten.

We generally use it to create dashboards through Honeycomb Enterprise. What we do is we have Splunk for separate things for getting the traces and debugging and examining what are the errors or if all our services are up to date. The tracking of the logs and tracing them through the trace IDs is separately done through Splunk logs. However, Honeycomb Enterprise we use for observing and debugging. We don't need any pre-built dashboards in Honeycomb Enterprise. It helps us in addressing the production issues very quickly and identifying the current outliers. That is the reason why we are using Honeycomb Enterprise. It is not just for observability and debugging, but also for health checks of the services to ensure that all the services are up and running steadily and what are the statistics so far.

We are utilizing Honeycomb Enterprise because it addresses multiple concerns at the same time, not just debugging and observability alone, but also checking the health checks of the services. We can even create our own custom dashboards utilizing whatever kind of graphs we want, a pie chart or even bar graphs for analyzing different aspects of our services to ensure they are correctly satisfying our parameters, which is the basis for which we are trying to root our observations. If you go for Splunk, then maybe you can just use it for observing and debugging using their log traces. That is quite limited. You have to use the queries also which can get complex when there is so much nesting in the queries or it has to handle a large amount of data. When we scale up the data set, at that time it becomes a challenge in Splunk. Whereas in Honeycomb Enterprise, it is a little bit made easier.

In Splunk we write custom queries and then we try to find the log traces, but in Honeycomb Enterprise it is very fast querying. It doesn't need many pre-built dashboards. It serves us by offering great support for high cardinality data. It is also very useful for distributed tracing.

In our enterprises we are using cloud native systems. We are using applications which have support for cloud technology. Honeycomb Enterprise is designed for modern cloud native systems. Honeycomb Enterprise has that cutting edge technology that we actually want nowadays. Observability and debugging, it is excellent for that. Splunk can at times maybe slow speed can be the cause which we will not prefer Splunk for that because if we have a large data set then maybe we will not prefer Splunk. We can go for Honeycomb Enterprise because the speed which is offered by Honeycomb Enterprise is much more than what we get in Splunk. That is why we say that we don't need to write the complex queries which we have been doing so far in Splunk. Here the advantage is the speed. It is less focused on traditional log management than Splunk.

There are a lot many negatives that Honeycomb Enterprise is having. One of them is that it needs good instrumentation and instrumentation to work properly. It is not as strong as what a traditional log management. It may not suit security compliance heavy teams. It can feel expensive when we have a large data set and when we want to engage a larger data set, and when many people want to be engaged for analyzing a particular issue. It is less familiar if your team is used to the dashboard first tools. Here we don't prefer pre-built dashboards. If the team is accustomed to using the kind of tools wherein the dashboards are already in use, then at that time it can appear as if it is less familiar. Honeycomb Enterprise's downside is that it is powerful for observability, but it can be harder to learn and maybe not fit every use case.

I have been using Honeycomb Enterprise for two years.

Glitches are a part of every tool and they do keep on happening. Mostly it is reliable, but at times, maybe one or two times in two to three months, these issues do happen. Sometimes errors happen in Honeycomb Enterprise or sometimes latency comes. That kind of issues sometimes happen maybe in three months, around one or two times. I won't say that it is fully robust, but at times it does give us some problems.

I think it can be expensive because if we want to scale it up, they are having some charges on that. At times we can be shocked to see that this price is too high for involving too many developers on one peak or having a much bigger data set or more advanced features for our use. At times I have seen that there are very high incurring costs noticed in Honeycomb Enterprise. Sometimes when our requirement is not too high, we may feel that it is a decent cost, but at times when we want more features, the cost sometimes is higher.

BubbleUp anomalies is actually a very important feature and it is very much used in our organization. Assume that you are having a total of 100 requests. One of them is very, very slow due to some cause, maybe there are some errors, some maybe downstream service might be failing due to which it is getting slow. But now the cause is, should we let all the other 100 requests suffer because of just this one request? The answer is no. To highlight what is the issue going on in our currently running 100 requests, we just highlight that one request which is very slow or maybe we just move it to the top so that we can alert everybody that this is the problem. All the 99 are okay, but the only issue which we are facing is with this single request which is very slow. What is the reason? We can identify that through the log traces again. If we see any odd patterns, then it automatically highlights them. Any outliers are there, so it makes them a bit visible so that we can make the investigation a bit fast paced. Unusual behavior can be highlighted to everyone so that we could be exploiting the solution that we might have, the developers we can engage so that they can rectify that problem and all the 100 requests are in shape again and do not cause the unwanted latency which we sometimes do experience just because of maybe one or two requests.

Since our teams involve multiple users and this is not just a situation where we are in one location, somebody might be from abroad. The team is quite vast and has everybody from every corner of the globe. What this means is that it enables everybody to log in and collaborate together and work on the single task. Sometimes when the major issue happens, just a single developer is not given the priority to be doing the same task and multiple users are required to be involved in this kind of issues at the same time. They can address the different aspects of the same, but the logs are common. The collaboration feature, which is a very highly rated feature of Honeycomb Enterprise is offered by it for keeping multiple logins for all the users across the team. That way we can share the data amongst each other. We can add the comments so that everybody can view what are the observations of some other person from some other aspect of the issue. That way everybody is on the same page. Dashboards can be viewed together. We can even sometimes see multiple people viewing the same dashboard at the same time. This is a part of this collaboration feature. This enables the team, the global team for investigating the issues together and not just investigating it, but also collaborating with each other to help each other and to resolve this issue in a lesser amount of time. That way everybody could trace the logs and keep tracking simultaneously. Suppose that if we are working on one issue, maybe some other issue also comes up, but few developers couldn't notice it, but the third one could notice that and can bring it to the forum and everybody could then work on that.

The installation and deployment procedure is quite easier. Basically what happens is we just want to put a tool into the system and it's easy for Honeycomb Enterprise. It's not that complex. I don't find it complex.

Honeycomb Enterprise helps the ROI by reducing debugging time, speeding up the incident resolution, and helping teams find production issues faster. If you do ask for cost, then I would say I am also somewhere in that much amount, approximately 10 to 20 percent.

Effectiveness means, Honeycomb Enterprise is very effective. We have all these kind of things structured tracing, collaborating feature, and data analysis. Honeycomb Enterprise is more effective than Splunk. When we are working on a large data set, we have a lot of values. High cardinality data support is offered by Honeycomb Enterprise, which means we can analyze lots of unique values. It helps in fast debugging. This is a major win. Fast debugging is what it offers. In Splunk, tracing becomes very slow if we have complex queries. That is something which we cannot afford to have when we are having immediate deadlines, very tight deadlines. At that time we need a very fast debug. If we build new dashboards, then even it helps in tracking these issues very fast. You have graphs also, you have a tabular format of analysis. BubbleUp anomalies again, because they highly, if any issue occurred in any of the request, it will be shooting it up directly on the dashboard and you can see from there that this is the issue, it is highlighted. We need to address it quickly because the deadline is nearing and it is a very close call. It has a good tracing support. It helps tracking the request across the services. It offers better collaboration because teams can investigate the incident together by this collaboration feature of Honeycomb Enterprise. Honeycomb Enterprise is effective because it helps teams quickly find, understand and debug unusual behavior in the complex systems.

Whenever we make a request, there is an inter-service communication. One service makes a request to another service. In that journey, we have a trace ID, we have a span ID, we have a service name, a status and duration. This gives us proper fields and the format to record the behavior of each request while it is making the transition from one service to another service. This is a transit. During this transit, we need to maintain the logs. Honeycomb Enterprise has given us a very good facility where we have a few fields. The trace ID is the main, span ID comes under it and the service name, status and the duration for which this request happened. This is one thing that we have these kind of format wherein these kind of parameters are there. But ideally, everybody looks for the benefit. That is one aspect that we have this kind of format, but what will this help in? It helps in finding the problem a bit faster. Anomalies, requests, wherever it went slower, wherever we found some bug or maybe the request got stuck somewhere. It is helpful in identifying it a bit easily and maybe faster. It is helpful in understanding that flow, how we are navigating from one request to the other request, what are the intermediate processes happening in between and whatever operations are happening between this one request, we have each thing properly formatted with the help of these parameters like the trace ID and span ID. That way we can probably identify the root causes of our if any issues occur. Even if the issues don't occur, then it is a good practice to keep the logs so that some or another day, maybe if you want to track yourself back to the previous logs, you can basically possibly track it. You can address the issue or maybe that aspect or behavior which you want to monitor in some time in the future.

My overall review rating for Honeycomb Enterprise is 9 out of 10.

We are the customers of Honeycomb Enterprise.

Basically, the purpose of using Honeycomb Enterprise is that it provides larger interfaces and dashboards for the logs of machines, terminals, and the debugging process is very easy because of Honeycomb Enterprise. Centralized logs are provided by Honeycomb Enterprise. We have integrated it into our services, including our deployed apps. So if any service goes down, any services are slow, or any APIs are crashing, then we use Honeycomb Enterprise very well for debugging purposes and tracing the logs between the services and microservices.

Structured Tracing gives the whole structure of a user interaction. If a user logged in, then went to this service and went to another service, then used this feature of our app or web app, Structured Tracing gives a full path. If we try to filter via user ID or correlation ID, we can see the full path a user has gone and how a user has interacted with the app or used our app, and where most people are going within our app, so we can analyze it, such as which functionality is most used by users.

We have used Honeycomb Enterprise in our services and deployed apps.

The biggest advantage of Honeycomb Enterprise for us is that it centralizes everything. For example, if we use AWS CloudWatch for a service, it gives logs for that service only. We manually have to search and scroll down over multiple thousands of logs for the crashing or slowing services. Honeycomb Enterprise basically gives a proper dashboard for everything. For example, if we have deployed multiple apps, if we are connecting it from Kubernetes, if we are connecting it from Docker, if we are connecting from a machine such as an EC2 instance, it basically handles all the logs. So whenever we need some logs, such as for slowing or crashing services, we just go into the dashboards, run some queries, and get those logs for certain time frames and fix the bug. This is how we use it, and it helps. It quietly increases productivity and debugging efficiency.

We just use the Bubble Up feature for identifying performance anomalies for API performance only. Because we have deployed our services including apps, web apps, and websites, we just need to figure out which service or which API for which microservice is going down or running poorly, giving some latency over the API calling. So we just analyze which service is running slow so we can increase its efficiency or make it better to use. This will increase our output.

One of the disadvantages or areas for improvement I see is that it is very costly. My honest opinion is that its service is very good, but for me as an individual, if I am using it in a small app, it creates a huge amount of data and it is very expensive to manage.

It has features for integrating into our apps, but regarding additional features, it should provide some global entry, such as a global SDK or system that captures the full services. We are facing an issue with integrating it. It provides an SDK to integrate into mobile applications or web applications, but we have to configure it manually in our services or microservices or APIs. It should capture all services by applying it globally on the app with the root of the app. Then it can capture the logs from the API calls. The root problem is that if we have 15 microservices in our app, we have to go and place it on the router, on the controller, and the service itself. So it takes place in every part of the code. That is the root problem. We have to hire two or three people that are masters in this platform and then apply the code in the codebase. So it can be improved via root SDKs so it can capture activity on a global level.

I have been using Honeycomb Enterprise for about a year.

Honeycomb Enterprise provides connections from everything in an IT company, basically. It provides logging, it provides connection with AWS, it provides connection with Docker, and machines, and local services, and mobile applications also. It covers pretty much everything for a software developing company or organization.

Honeycomb Enterprise is reliable. I can say it is around 98 percent reliable. It sometimes lags for larger systems or larger microservices, or for larger databases stored within its database. So I can say it is 98 percent reliable and productive.

If we use it in a larger platform which is regularly used by users, it creates a huge amount of data. It captures all the logs if we integrate it in our services. Then there is a huge amount of data, and it takes thousands of dollars per month for an enterprise level. So if we compare it to other tools, its service is very good. I know that. We know that its service is very good. We get interactive dashboards and features for filtering out and tracing the whole process. But if we talk about the pricing, it collects a huge amount of data, which then creates the large pricing for the enterprise level.

I am happy with Honeycomb Enterprise's customer service because we have never called them because we have never felt the need to call them. We have never faced an issue with Honeycomb Enterprise. Our main goal is the debugging process from Honeycomb Enterprise. We achieved it, and it is seamless, and we have never faced an issue with it.

The initial setup and deployment procedure for Honeycomb Enterprise is straightforward. It is quite simple to use. We can just deploy via Docker or Kubernetes and these kinds of services. Honeycomb Enterprise provides quite a good setup for using these services. It provides the OpenTelemetry SDK and the Honeycomb Enterprise SDK also. So we can just use and integrate with these systems including Docker and Kubernetes and make the deployment process very seamless and very easy. It is quite interesting to use it, and we can deploy products seamlessly.

If we talk about how I compare Honeycomb Enterprise to its competitors, I would say that if we talk about the competition such as OpenTelemetry, Grafana, some people are still using them because of their pricing only. The major factor is pricing. I just want to say the major factor is pricing. We have a banking system that is generating dozens of logs. So we are facing the pricing issue, which is thousands of dollars a month, so it is quite expensive. If we use Grafana and other tools for logging and capturing these analytics, that is a time-consuming process but less costly. So that is the major issue with the competition.

If we speak about whether Honeycomb Enterprise is worth the money, I would say if we speak about enterprises or companies such as mine, we have dozens of applications we have developed or deployed or are running live. It provides a single dashboard for all of them. We can select projects and see their logs and debug from there. Basically, it is based on OpenTelemetry. So, OpenTelemetry provides great graphical analytics. We can trace each and every call from there, historic calls also, from two or three years ago. So, it helps a lot in debugging. What does a developer need? If a bug came out, if a service fails, then we should work on it immediately. Before, we had to watch AWS CloudWatch logs and see terminals of the EC2 instance machines. So, that is quite time-consuming and very irritating. This resolves all of that because we have a dashboard and we can run queries to get these error logs. For debugging, we can just run queries such as what API is taking more than five milliseconds. It is just amazing working with it. We can get directly what we want within the time frame, and it helps debug the code and the terminal. I gave this review a rating of nine out of ten.

I received information from your team regarding a peer review of Honeycomb Enterprise. As an observability engineer using Honeycomb Enterprise extensively, I can provide substantial input. My primary tasks involve OpenTelemetry, where I send numerous traces and metrics to Honeycomb Enterprise and use it for visualizations of how our code is functioning and how data moves through our systems.

We have identified many problems using Honeycomb Enterprise, such as delays in the system where latency is observed by Honeycomb Enterprise traces, which we then investigate further and resolve. We have our SLA and SLOs configured on Honeycomb Enterprise, allowing us to monitor our reliability score. Additionally, we send many metrics to the platform. In my previous organization, we used it only for traces, but in my current organization, I use it extensively for traces, metrics, SLA, and SLO work. We also use Signoz for infrastructure-related APM metrics and other things, but we cannot use it for Honeycomb Enterprise capabilities.

Honeycomb Enterprise has genuinely helped us. We are not using Honeybee command line, which is a native solution by Honeycomb Enterprise. Instead, we use OpenTelemetry so that we can switch vendors easily. Our complete codebase now has proper telemetry data sending into Honeycomb Enterprise.

We have provided traces for each of the functions we are using. If we need more in-depth insights into what happens inside the code, we set up additional telemetry data points in the code. When you set those telemetry data points there in the code, you send those traces to Honeycomb Enterprise and then we can examine them.

In terms of customer usage, observing how customers are using our solution is very helpful in debugging aspects and also helpful in cost prioritization aspects. If a customer is not using our solution extensively, we can scale it down a bit in terms of servers where our solution is running. This has given us a better approach, particularly for Lambdas where Lambdas are deployed, and we can save considerable costs.

If traffic is not very high and we are able to see metrics where traces are not falling a lot, we can scale down our instances and save our AWS billing. If there is a sudden spike, we can get that monitored via the SLI and SLOs that I have configured. If there are sudden errors, I can scale the instance up.

If there is a genuine bug in the code, Honeycomb Enterprise is very useful for debugging the issues. Even a data-driven issue can be fixed using it because we get all the data when a user is providing any request. We actually get the input data in Honeycomb Enterprise and that way we can solve it very fast by seeing what query they hit or what workflow they have done.

Tracing is undoubtedly one of the best features they have developed. Tracing is basically the story in the code showing how the data is moving through. That is something which is extremely good. I can vouch for Honeycomb Enterprise, and that is the reason I brought Honeycomb Enterprise as our solution in my current organization.

That is the best thing Honeycomb Enterprise has done. In the past, in my previous organization, we were using something called GCID where if you send data, GCID is basically each document we are receiving. We were using an enterprise solution there called Smarsh. In that company, we were getting almost five petabytes of data per day, so that is the volume I was dealing with. Honeycomb Enterprise was actually really great in terms of tracing. We had a sampling rate and we were not sending all the traces, but the best part is we were able to add more cardinal events, such as GCID, which was getting mapped in each and every document. We were sending those metrics blindly and we did not have to think more about it. The amount of engineering that Honeycomb Enterprise has done is actually handling it very well. At that scale also, I can vouch for Honeycomb Enterprise that it manages traces beautifully.

That money is well spent. We do not have any complaints because tracing is something which is extremely good. How they cater to it and how they manage it is excellent. It is an extremely cost-effective solution right now in the market as compared to its peers like DataDog and other companies.

Throughput is something which I was using previously. There were around twenty million ingestions in my previous organization, obviously. Here the scale is not very high where I can challenge the engine. In my previous organization, when there were twenty plus million ingestions of data every day, in those kinds of scenarios, Honeycomb Enterprise actually stood very well. The major solutioning we were using was for traces. We were not using it for metrics. So if there are more data points, there might be a crash in Honeycomb Enterprise. However, honestly, I have not used it at that scale, so I cannot comment exactly on that point. I have used it for metrics and that performed well, but not on a very high volume of data where I can challenge the engine itself on how it is processing.

I would say it worked pretty well for mid-tier or similar tier companies. I do not have any complaints. But for enterprise solutioning, probably when a lot of data points come in, DataDog obviously has an edge there. They are actually the market leaders around it. They have better metrics, APM, and other aspects there.

Honeycomb Enterprise's tracing solution stands out. Whatever they have built, they have built an excellent product there. Honeycomb Enterprise actually works very well with traces. When you send traces, you will get the complete view of the life of the code and how it has been executed.

The only complaint I have is that even though we are on a paid tier where we are paying one hundred thirty dollars per month, we are still lacking the amount of ingestion we have to do. It counts each and every event. We cannot blindly send the performance metrics and other things directly to Honeycomb Enterprise as it will raise our bills. They have some buffer protection, but that only happens twice or three times a month. After that, the number of events will get billed accordingly.

On the negative side, dashboarding is not that great. I have used solutions like Signoz which are open-source and Grafana. In those platforms, where we have open-source solutions where we are sending in the metrics, we are getting a complete dashboard and a complete solution around it where we can analyze everything in one shot. That is not something which is really great with Honeycomb Enterprise.

These kinds of solutions in Honeycomb Enterprise feel very difficult to build because I think it is an over-engineered product in terms of metrics. For traces, I have to give it to them. They have done an excellent job.

The only thing is the UI is not that great for Honeycomb Enterprise. That is something where it is not very appealing when I am looking into it. It is more of an engineered thing. I am an engineer and I understand this. You cannot make the UI very beautiful. However, if you use its peers, such as DataDog or Signoz, there are very interactive dashboards and other things. The dashboard is not that great, honestly, in Honeycomb Enterprise.

There is a cold start problem because we were using something called Lambda in AWS. The cold start issues basically occurred because we had not provided proper RAM to our Lambda function. Because of that, the Boto3 boot up was taking a lot of time. That was caught during these tracing sessions when we added the traces. We were able to identify that the Boto3 startup, the init part of Boto3, was taking more than twelve seconds or ten seconds to boot up. That is basically a very huge latency when it comes to a SaaS product.

Those are the major things. One thing they should do is discontinue Honeybee CLI. Right now, no one is using Honeycomb Enterprise like Honeybee CLI as per my understanding. Very few people are using it, and only POC kind of things are happening on this. People are shifting to OpenTelemetry. They should actually discontinue that product. It does not make much sense because they are trying to bring a dependency on people who are using that and they want to lock them into Honeycomb Enterprise because once the code is telemetered, it is very difficult to change it again.

However, now with cloud and everything we have, it is very easy to make those changes. There is no mode there. If there are engineers around it who are managing those things, they can actually shift to a better place where they can provide more value around it. Because people will eventually move to OpenTelemetry where they will set up their OpenTelemetry system, one OTel collector, and then OTel collector will send everything to Honeycomb Enterprise. People are moving out of these enterprise solutions mostly and they are using OpenTelemetry day in and day out. Most of the architects I talk to in terms of these things always talk about this.

Personally, I have also not used Honeycomb Enterprise CLI. I have read a lot of things and articles around it. They are actually maintaining it very well it seems, but I think they should discontinue it. That is just my opinion based on my observations. I may be wrong, I am not sure. This is what I have observed during communication channels, followed by the usage I have done, and followed by people I talk around. All have similar opinions.

I have been using this for almost three and a half years now.

I have not had any stability issues.

The setup is pretty easy. That is straightforward. I do not have any complaint there. The documentation is well written. I set up Honeycomb Enterprise traces just for a POC kind of thing within less than thirty to forty minutes just for a small code. The actual production code took one day, but that is because the code was long. That was easy. It was not very difficult. Things were very clear around it regarding how to generate the API keys to send those things and how to send it.

The load balancer API of Honeycomb Enterprise is extremely good. It accepts everything. I do not have any concerns there. I have never brought it down. I am not sure about the reliability aspect of it, but it accepts everything and I have never seen it down in my experience. I do not have any concerns there.

What we have done in terms of ROI using Honeycomb Enterprise, I still remember one use case where we reduced our overall latency because there was one Boto3 library which was not getting the expected performance.

Honeycomb Enterprise played a vital role in identifying the problems in the initial calls itself. That has actually saved us a lot of incidents. Previously, there were a lot of customer complaints coming in. I have taken one step at a time and I have added all these things in our code and followed by the customer complaints are almost ninety to ninety-two to ninety-three percent down as per the data I have.

Honeycomb Enterprise has actually helped us in various ways. The major complaints were around latency. We were able to switch our databases also because there was one problem that was identified by Honeycomb Enterprise where we were trying to fetch more than one megabyte of data from DynamoDB at one point in time. However, the problem was there is a hard limit set to DynamoDB to fetch these kinds of data.

That was a serious problem because customers were expecting data what they want to see on their screen. These kinds of issues were identified during our initial checks on DynamoDB and we were able to move to Snowflake. This has given us better solutioning around it.

In those scenarios where you are not getting the complete data to the customer, it will cap the data to one megabyte.

For tracing solution, definitely, I will always suggest Honeycomb Enterprise is a better solution. Other observability solutions out there are expensive and they are not that reliable in terms of tracing, to be honest.

If there is a genuine bug in the code, then Honeycomb Enterprise is also very useful for debugging the issues. Even a data-driven issue can be fixed using it because we get all the data when a user is providing any request. We actually get the input data in Honeycomb Enterprise and that way we can solve it very fast. We can see what kind of query they hit or what kind of workflow they have done.

I think people are very resistant to adopting Honeycomb Enterprise. If you see the community, I am in the Honeycomb Enterprise community right now. I usually ask a lot of questions there. Now that AI came, the questions volume has decreased significantly. However, previously it was a very healthy community where a lot of questions came in. If you go through those questions, the major things are around how to set up things. It is not always about the metrics cardinality or how things are not working around it or if there are any solutions.

I would say it worked pretty well for mid-tier or similar tier companies. I do not have any complaints. For enterprise solutioning, probably when a lot of data points come in, DataDog obviously has an edge there. They are actually the market leaders around it. They have better metrics, APM, and other aspects there.

My overall review rating for Honeycomb Enterprise is eight out of ten.

I was using Honeycomb Enterprise for checking the logs and for application purposes when we were trying to find bugs and errors in a particular application. We used Honeycomb Enterprise for HTTP status codes and responses such as GET responses or POST responses and error messages. The solution part and root cause analysis were primarily handled using Honeycomb Enterprise.

Regarding BubbleUps, I have not utilized it directly, but the engineering team has utilized BubbleUps and they used to submit reports to us.

I have used the tracing feature, which is one of the most efficient ones. In that particular scenario, we can check even a single thread and each thread can give us detailed analysis of what exactly happened. We used this for deep root cause analysis when we required investigating a particular issue in depth using threads.

Our engineering team and my team are working on Honeycomb Enterprise for collaboration. This is a very efficient feature because if someone posts something, it goes directly to every team and every team member who can access Honeycomb Enterprise logs.

The most valuable feature of Honeycomb Enterprise for me is the root cause analysis part because it helps me greatly with the response messages and derived error messages which are very clearly mentioned in Honeycomb Enterprise logs. This helps a lot to pinpoint the particular issue and provide the resolution. It helps us with resolution time for our customers and clients. Honeycomb Enterprise helps a lot in tracking and monitoring bugs efficiently on a real-time basis.

Honeycomb Enterprise actually reduces the resolution time for clients if we are working on any particular issue. This is very efficient, and root cause analysis is also a big feature which helps a lot.

If any particular issue is going to take half an hour for root cause analysis, by just getting the error code, particular HTTP status codes or response error messages, we can pinpoint the issues within a few minutes. Approximately 15 to 17 minutes will be reduced. If we are not able to get any particular response time or any particular error message, then we are not able to pinpoint the particular issue, which will take some time. However, Honeycomb Enterprise actually reduces all that particular time by giving that particular message efficiently.

Regarding other aspects, I cannot comment fully because we only use that particular part for tracing the particular threads as per the issues and there are multiple issues in which we have not used it. We are not frequently using that particular part.

I have been working with the solution for application support in my current role for the last 6.5 years.

The stability part is very impressive and good. Regarding availability, I did not face any particular issues in my company. My team also did not face any particular issues as compared to other tools. In terms of stability and availability, this is an impressive one, and if something happened and some issues came up, then it was resolved automatically.

I have been using Honeycomb Enterprise from the beginning when I started in this organization, and they were using Honeycomb Enterprise only.

Other than Honeycomb Enterprise, we were using the Grafana tool. Grafana is basically for real-time analysis of issues with the help of visualization techniques. We can check the graphs according to performance such as CPU performance and memory utilization and other things. We can identify that CPU utilization is high or memory utilization is high, and we can proactively work on those systems and try to resolve the issues proactively so the system will not be affected.

I have read about Honeycomb Enterprise's query engine and the visualization part, which is very interesting. However, those decisions were made by the top leads, so I am not part of that decision. According to me, that is interesting and we can use it.

Grafana has a visualization technique in which it shows the spikes and different structures if some bugs came up and sudden changes happened in the visualization. We can directly identify that this could be happening and this is the bug which we can implement. If it provides us the report in real time, then that would be better so we can proactively inform the clients and other clients who are using the applications and we can improve our methods and systems.

Honeycomb Enterprise and Grafana are tools for similar techniques, but I can say a few things which can be implemented in Honeycomb Enterprise. The feedback which I have given for Honeycomb Enterprise is relatable for Grafana as well because I was using the same technique with Grafana and we can implement the same technique in Honeycomb Enterprise, then that will be great.

I have not used certain features, so I cannot comment on those. I believe I have shared feedback which I think is good from my perspective, and I have shared that feedback accordingly.

My review rating for Honeycomb Enterprise is 9.5 out of 10.

Honeycomb Enterprise is used in support of global clients for observability and debugging cloud-native applications. It is utilized for tracing different types of observation of processes and tools as an automated tool. Depending on client requirements at global locations, Honeycomb Enterprise is selected from among other competitors.

For example, work with refineries within the energy space has involved using applications supported by Honeycomb Enterprise to understand and support clients in those projects. This includes understanding their processes and observing the different applications they use within AWS and the enterprise version. Using these tools, numerous different processes within the energy sector have been observed, and Honeycomb Enterprise is used for refineries and other operations. In specific cases, processes and how applications are run are observed, and different metrics like Honeycomb Metrics and other tools within the Canvas and other available options for model content protocol are used for different approaches. Anomalies are detected as part of MCP, and then efforts are made to debug those anomalies and work with the applications. For all clients, the process is generally the same, though specifics vary by application.

Honeycomb Enterprise is generally used to observe processes, understand anomalies, detect them, and work with applications to debug problems that surface. One challenge is that many things have to be defined manually and are not totally automated, while some competitors used for different projects or clients do have automation. Despite this, Honeycomb Enterprise remains a good tool for these purposes.

More automation would be great with Honeycomb Enterprise, as some competitors have more automation in this area. Dynatrace and others that have been used do provide more automation. Frequent evaluations of these tools against each other within the competitive landscape are conducted, so there is definitely room for improvement, and more can be done with Honeycomb Enterprise. However, at the moment, there is happiness with some abilities like natural language interactions and creating live diagrams through the process, which are all advantages that are beneficial.

Further automation of Honeycomb Enterprise and a reduction in the number of manual inputs currently required would be very beneficial. While it is known that they are working on that, some competitors already have automated features, with Dynatrace being one of them, and Grafana providing telemetry standards and other features. There are other things that could be done regarding further automation to reduce manual input, which does create challenges and slows progress.

Debugging could be improved with suggestions for improvement or for solving the problems. If suggestions were provided in the process of debugging, that would also be very helpful with Honeycomb Enterprise.

The AI capabilities of Honeycomb Enterprise are good, and this is considered positive. The interaction with these capabilities has not presented any issues.

In terms of accuracy, there is room for improvement, and for reliability, results are usually compared with other data and other approaches used for specific projects to ascertain that the results obtained are accurate. Since it is still in early stages and early use, full reliance cannot be placed on everything obtained from it. Results have to be compared and common sense and due diligence must be applied with other observations and analytic work to qualify the results. In terms of security, no breaches or issues have been noticed.

Honeycomb Enterprise offers excellent features that include the ability to define different triggers. Within Honeycomb Enterprise, 300 triggers can be defined, and different activities like single sign-on can be performed using various service level objectives available within the enterprise package. Queries can be defined manually, providing significant customization and the ability to customize and define as needed. Since it is cloud-native, it helps because applications supported are that way for global clients. Most importantly, Honeycomb Metrics for debugging and identifying issues and anomalies is a good step, though it is not sufficient because clients require remedies for the challenges encountered. The ability with Honeycomb Metrics in particular to debug those issues is very helpful. These advantages stand out for the enterprise version as opposed to Pro, where only two triggers can be defined, but in Enterprise, 300 or more can be configured.

The feature relied upon most day-to-day is Honeycomb Metrics. As a consulting company solving problems, identifying and solving issues is really important, and this feature facilitates workflows and expedites and provides efficiency within processes. It gives access to tools and techniques that would not otherwise be available.

Efficiency improvements in processes with Honeycomb Enterprise have definitely been seen, and the most representative example is that more projects can be handled than could be done prior to using Honeycomb Enterprise. Issues for clients can be resolved in an expedited fashion, and more projects can be accepted, making these efficiency improvements quite advantageous.

Honeycomb Enterprise has been used for the past five years.

To the degree expected from Honeycomb Enterprise, it has been stable.

In terms of the number of triggers and service level objectives, Honeycomb Enterprise's scalability is good and adequate. In terms of adding team members or multiple team members using it, no challenges have been encountered. Since we are a relatively small consulting practice, only that perspective can be offered.

Dynatrace, New Relic, and some other tools like DataDog have been used for different purposes and some for observability. Honeycomb Enterprise was not necessarily switched to but rather added to the suite of tools used for different projects.

New Relic, Dynatrace, DataDog, and Grafana have been considered as alternate solutions.

About 30% more projects can be handled than prior to the use of observability tools as a whole. Although more than one type of tool is used because diverse clients with different requirements are served, in general, 30% improvement has been observed. This is measured based on the number of new projects that can be taken and the revenues that can be generated as a result. Due diligence and evaluations should be conducted before choosing if Honeycomb Enterprise is optimum for what is required. The review rating for this product is 6 out of 10.

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.

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 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.