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.
My main use case for Honeycomb Enterprise is monitoring microservices, tracing API requests, identifying performance bottlenecks, and troubleshooting latency and errors in my distributed systems.A typical example of how I have used Honeycomb Enterprise to troubleshoot is with slow payment processing APIs, where Honeycomb Enterprise's distributed tracing helps identify whether the delay comes from a database query, an external payment gateway, or communication between microservices. Another important use case is improving visibility across distributed services, which helps teams identify recurring errors and monitor API performance while reducing troubleshooting time.
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.
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.
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.
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.
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.
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.
Customer Support Engineer at a insurance company with 10,001+ employees
Real User
Top 10
Apr 28, 2026
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.
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.
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.
Software Engineer at a financial services firm with 11-50 employees
Real User
Top 20
Feb 6, 2026
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.
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.
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.
Honeycomb Enterprise delivers distributed tracing, real-time performance monitoring, and high-cardinality data analysis to enhance observability, scalability, and incident response.Honeycomb Enterprise provides organizations with the tools needed for debugging and performance optimization in complex environments. Utilizing features like BubbleUp and powerful querying, users gain end-to-end visibility and reduce troubleshooting time. Integrations with DevOps tools and customizable dashboards...
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.
My main use case for Honeycomb Enterprise is monitoring microservices, tracing API requests, identifying performance bottlenecks, and troubleshooting latency and errors in my distributed systems.A typical example of how I have used Honeycomb Enterprise to troubleshoot is with slow payment processing APIs, where Honeycomb Enterprise's distributed tracing helps identify whether the delay comes from a database query, an external payment gateway, or communication between microservices. Another important use case is improving visibility across distributed services, which helps teams identify recurring errors and monitor API performance while reducing troubleshooting time.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.