At QuintoAndar we have dozens of engineering teams maintaining over a hundred services. Honeycomb became the go-to solution when we need to dive in and understand what is happening with them. Our biggest use case is by far troubleshooting incidents. Thanks to Honeycomb's blazing fast query times, once we know something is wrong, we are often able to quickly pinpoint exactly what is going on and fix it faster than before. But we also started to use it to keep track of Service Level Objectives and even help onboarding new engineers, for example by showing some ways user requests map into our infrastructure. Finally, the customer support was great. Since we started the trial we had a direct channel with both their sales and engineering teams who were always very quick to answer any questions and act on any feedback.

Honeycomb has made it very easy to ingest any kind of structured data and "slice and dice it" to figure out what is really happening with our systems. We have extracted a lot of value from database query logs, load balancer logs, CDN logs, even Kubernetes events! However, it's at analyzing application traces where it really shines. The game changer is the "bubble up" feature: it tells you which dimension of an event is more likely to be responsible for an anomaly, and that is super useful when you are troubleshooting an incident or want to answer tricky questions such as "which API calls are causing us to not meet our Service Level Objectives?". Finally, I have to add: Honeycomb's pricing model (event-based instead of machine/CPU/license based) is probably the most cloud-friendly option out there.

Some aspects of the UI/UX could be improved. It is easy to jump on and start asking meaningful questions about your data, but it can also be a bit overwhelming to new users who are more accustomed to more traditional "point-and-click" interfaces. The online interactive tutorials are very well made and do help a lot though.

We used the FREE tier to test the product, and now we just started with PRO and are looking for getting all moving parts instrumented. Already showed benefits by not having to jump between multiple tools, but we expect to get even more in terms of the knowledge sharing and culture around observability and on-call in our org.

Honeycomb helps engineers deal with complexity. It rewards curiosity and makes lowers the unnecesary cognitive load for engineering modern systems. Ultimately, improves quality of life for engineers.

The instrumentation and the decisions about sampling can make or break the value users get from HC - and currently (especially for PRO subscriptions) the focus is more on the end result and not that much on how to get there.

Honeycomb does exactly what it says it does. The flexible data model means we can freely instrument our code without worrying about massaging it into a form that it will accept. In fact, our codebase was already instrumented using OpenTracing before we adopted Honeycomb. We were able to point our OT client to Honeycomb (via a proxy they provide) and it just worked. The query engine is flexible and fast, which makes it easy to explore our data without demanding intimate familiarity -- this is critical when debugging issues in a distributed service where I don't always know exactly how the events are structured, or what exactly I'm looking for. Honeycomb's event-based pricing model means we can shove whatever information we think might be useful into our events without worrying about blowing the budget. This is critical to maintaining a well-instrumented codebase, as we don't want our developers having to make value judgements about what to report during development. Combined, these attributes mean that any question I can think to ask can almost certainly be answered by Honeycomb. It does not take long to become dependent on this ability. In fact, when our trial period was about to expire, a member of my team said, "you can pry Honeycomb from my cold, dead hands!"

Honeycomb is excellent for exploring the system to get to the bottom of an incident. However, it is less useful for more classic monitoring use-cases. It does have dashboard and trigger features, but they are fairly rudimentary at this time, and insufficient for proactively monitoring the health of a complex service. In Honeycomb's defense, they do not position themselves as a monitoring solution, so this isn't particularly surprising, but it does mean that a separate monitoring solution is also required.

I am now requiring Honeycomb integration on all software I build and help maintain. It is the highest praise I can give.

It opens up new avenues in software engineering: what if you could ask your system how it's doing? Instrumenting everything, sampling sanely, and all the relevant data is in Honeycomb at a reasonable price. From then on forward, all the querying options are available. Bubble Up is there to help massively during incidents to find the outliers and where the problem lies. Once this is implemented properly( not an easy feast), it feels like living in the future.

Coming from a classic( and wrong) observability=logs+metrics+traces mindset it is rather hard to get accustomed to Honeycomb. Once the mental hurdle is passed it's all sunshine and rainbows, but it takes a whole lot to get there. Fortunately, their Solution Engineers are very patient and helpful.

Very easy to set up and get data into Honeycomb. We leverage AWS Lambda extensively and send all of our Cloudwatch log groups to a Kinesis stream, which another Lambda consumes & publishes to Honeycomb. We've been able to find patterns that would have been difficult to surface in other tools and the SLO functionality provides a good target for your application.

The ability to explore your application data in ways you did not know you needed, but once you get a taste you're hooked.

I can't think of anything about Honeycomb that I do not like. One thing to keep in mind when implementing it is to ensure your log data is well-structured with standardized field names, otherwise you won't get the most from it.

Honeycomb is what you get when you put really smart Ops people together with really smart Dev people to solve both of their problems. The APIs have been very reliable. I haven't lost a byte. The bytes I expect to be there are always there. Outages are well communicated and quickly remediated. Plenty of transparency. Every single person I have interacted with at Honeycomb over the years have been great to work with.

The query interface is a joy to work with, literally. It is literally the product I've wanted for decades. I even started building pieces of it a very long time ago internally, but Honeycomb makes every prototype I've ever built look like the toys they were. I can't say enough good things about it. The query history and social debugging features are GREAT and are a good example of how the overall Honeycomb philosophy of promoting engineer happiness shine through. I trust that the product choices they make are as much to make my job easier as it is to make buckets of money. I could be here writing for hours and I don't know what the character limit is here, so just suffice it to say that the Query UI is amazing, the data ingestion APIs are very good, everything is well and thoughtfully designed and I can use them in a myriad of fully supported ways. Nirvana!

The only con I can think of is a lack of off-the-shelf support for PHP, which we still use quite heavily. Support is getting there through OpenTelemetry, etc. Getting data INTO Honeycomb can be a challenge, but in the year and more that we've been using it even that con is shrinking, and quickly.

I historically hated debugging and metrics and charts, but even just the content being generated at Honeycomb for the industry is as amazingly helpful as the product itself. Honeycomb has brought me into the SRE world and helped me lobby higher decision-makers in the value of observability. They have a wonderful community, are committed to support/ customer success, provide open office hours with incredible industry experts, and every interaction has been encouraging, positive, and helpful.

The UI is so incredibly powerful and intuitive, even for a non-SRE like myself. Dive into trends and their traces in seconds--consistently successful and fast loading already takes a lot of pain out of debugging. I have big plans for using Honeycomb's APIs and integrations to validate and even make decisions in our CI pipeline, something I could never quite all-the-way envision before I got my hands on Honeycomb.

They try to make everything easy, but sampling is not easy and figuring out what to trace, how to trace it, and knowing what will "come out of the box" is still difficult. The level of effort required to get off the ground has been difficult for me, exacerbated by my own ambition and enthusiasm.

Absolutely brilliant. Couldn’t run this product with such a small Ops team.

The insight that Honeycomb gives you is completely unparalleled. We often go to a being alerted to an error to a root cause in a handful of queries. 5-10 min. But also it is great to browse through your data and see how a change you just put live is performing. We often pick up small issues way before they become big or any customer notices. Ready access to all events is phenomenal.

It can take a bit of time to get used to the UI. They made a bunch of improvements lately though.

It has been fantastic to see how fast we could get up and running as well as how welcoming it is for people to start from the position of other people's queries and build from there. It does take some investment as it is a different way of thinking about our services but when and where we have done this it has proven invaluable.

Honeycomb provides quickstart libraries called beelines that have helped us get up and running quickly. Once basics are in place, it does require some investment to get the right data in. This has actually proven valuable to us as we have found places to dig in based on strange behaviours in our graphs. In addition the search history being forever available and serachable across the whole org has helped to share knowledge and context.

There are two major query features that are currently being talked about but would help tremendously. One is to be able to query for span details at the trace level. The other is to have a sql style `having` in the query. Not having these means a bit of creativity sometimes but haven't been showstoppers for us.

Honeycomb is the first tool I use when checking for potential errors in our application or just to view our logs. It was crucial when debugging performance issues with our database by allowing us to quickly add instrumentation to our code and start sending it to Honeycomb.

- Easy to run aggregates across multiple fields, time ranges, and filters - Can send custom events to add instrumentation any where in your system - Building dashboards to save and group common queries is great for collaboration - Queries execute quickly (usually in a second or two) - Can click on fields to filter them out from results or drill down to just them - Autocomplete on all inputs

- Hard to know which queries to run if you don't have a good grasp of the log fields you're sending

We went from scratching our heads with unintuitive and clunky Cloud-Platform native log parsing and monitoring, to immediately actionable data. As trivial as it sounds, "Group By" on metric data is a game-changer.

How easy it was to deploy a helm chart and immediately begin collecting data from pretty arbitrary services in a kubernetes cluster.

It would be nice if there were SLO support for non-Enterprise versions. Also, more integrations with other SaaS products would be nice.

No more bumpy as any other complicated observation tool being wired into a complicated internet scale platform

The ability to see what is happening across the span of any business event without our product is amazing. You can find any outlier event and then dig into why that event was triggered with detail and across time

Implementing the hooks to generate appropriate span events can be daunting because it's so different. Getting the data gathering to include appropriate information when you have both standalone servers and container clusters was a challenge

Honeycomb gives us the ability to see deeper insights about individual requests flowing through system in a way we haven't been able to achieve with any other monitoring / metrics product.

Customers will get the most value out of Honeycomb if they spend the effort to deeply instrument their application with fields specific to their application and business. This can be a high learning curve initially, but the payoff is well worth it.

It's really easy to get started, entry cost is really low/almost free. But it takes a while to get a good hang of the platform and the value it can provide. Once you are used to it, it's hard to imagine working without it.

It was very easy to get started with Honeycomb! The free tier is generous and the Beeline provides decent instrumentation out of the box. My team was willing to experiment with new tech but we couldn't invest a lot of time. We started out by including the Spring Boot Beeline into our app, configure a API key and we were off sending events!

I find it hard to find a thing about Honeycomb I really dislike. While the platform is missing features here and there, none of them are show stopping issues. They are mostly opportunities for Honeycomb to grow and I've noticed things are constantly changing and improving.

Delightful.

Fast and flexible queries, easy enough for the whole team to learn.

The query builder UI can be annoying to use (I'm a power user).

Honeycomb was a game-changer for my team, it took us a few minutes to understand how to run queries and after we ran a couple of them we immediately discovered some interesting utilization of our platform that we weren't aware of, specifically, we were able to understand the usage by customer and in which way are they leveraging our platform, that is, which tools and its versions, accessing via the UI or API, etc.

At first glance, our account didn't have much data to explore, most of the main graphs said so and, even though I continue to use the platform weekly, the same graphs without data will continue to show up. My feedback here is to improve the user experience by showing the graphs that I work with, there is definitely data I am using but those datasets and graphs are not shown upfront, it would be great to see them right there after I log back in.

Being able to start from a basic view of your data set, and then drill down into what exactly are the sources of your problems is pretty much a superpower.

It sucks to have to do the work to integrate it - but it's worth it. I figure it's the cost of doing business.

Able to gather many different data from different aspects to find the website loading or other concerns, fast to get to the point that solve the problem for better user experience.

They have very great chart dashboard that we're not working in the dark. They have different filter options that we can research details and getting more deep level of issues.

So many options and selection for analyze our site requests and responses for tracking the real issues. Time consuming with this tool might be a concerning, we might able to improve it with UI tooltips or guiding wizard.