My Struggles with LogRocket
It pains me to write this post, because I really am a big fan of LogRocket. For uninitiated, LogRocket is a tool that allows developers to not only capture errors that occur on different browsers, but to actually replay their sessions, displaying the user's screen when the error occured, as well as a Chrome devtool-like console with the network request responses, logging and more. The product has been very helpful in finding issues that we would never encountered in any other way, and to be proactive in addressing bugs before the inevitable client ticket.
So you would think that a company specializing in fixing bugs would be on top of fixing issues on their own product. But strangely enough, that hasn't been the case. In fact, as the issues below show, not only have fairly obvious bugs not been addressed, but communication from the company has been almost non-existant:
The Source Map issue.
Like most companies with a relatively complex site, we don't burden our customers with having to download millions of lines of JavaScript -- instead we minimize them into bundles to speed up load times. This does make it trickier to debug an issue with LogRocket, since the errors that appear in the tool show only the stack trace from the minimized file rather than the full line item. To address this, LogRocket provides a command line tool to upload source maps, which which are then coupled with the minimized file to provide more complete diagnostic information. However, when I attempted to do this with our scripts, it simply didn't work. No problem, I thought -- most likely an error on my end. I sent an a ticket, and went through a full back-and-forth with an engineer. Then, one day, without warning, the engineer disappeared and stopped responding to my emails. My last message from him (over two months ago) was thanking me for my patience. Part of me hopes that he's travelling the corners of the earth, visiting remote and mystical IT departments in distant quarters desperately trying to resolve my issue. The more cynical part of me thinks that he's basically given up and is actively trying to ignore me. Unfortunately, LogRocket's substandard ticketing system, with no ticket numbers or ability to check issue status, makes it very difficult to find the answer.
The Custom Traits Issue.
One of the features I was excited to implement when setting up LogRocket was custom traits. This functionality allows a specific 'trait', or user property, to be passed to the monitoring service with each request, so we could more easily search and identify which users are having issues. Since most of our clients have multiple departments, I set up a 'departments' trait, so when we looked up a client, we could determine which department they belonged to. Unfortunately, when our QA analyst tested it, he got a rather unpleasant surprise: every session for an organization was classified as the same department. It seemed that the department for all sessions was automatically set (or reset) to the most recent session recorded by LogRocket. Again, I submitted this (with full video), was told that it was going to be looked into, and then got no follow-up. What shocked me about this issue was that I was literally using the the feature 'out of the box' -- even the most basic of testing would have caught it. It really makes me wonder how much quality assurance was conducted by LogRocket on this feature (or any of their features) before being released.
The Symbol Undefined Issue.
The issues above were based on features that simply didn't work as advertised. However, we experienced an even more grave issue when we started noticing errors during testing on Internet Explorer 11 (the browser of choice for our corporate users), where our site would literally stop working. It turned out on closer inspection that LogRocket was triggering a 'Symbol' is undefined error, which was literally stopping script execution. When we removed the LogRocket script, the site magically started working. Again, I submitted a full video replay, was told that LogRocket was looking into it, and then once again, was treated to the sound of tumbleweed drifting through the desert.
I want to re-iterate that I'm still a believer in LogRocket, and want to keep it as a part of our solution. But as a small company that needs to carefully evaluate where we invest our development dollars, it makes it very difficult to justify paying a not-unsubstantial amount of money to a company that doesn't seem interested in fixing its customers' issues. It's my hope that LogRocket can pull themselves together, bring back the support team from the black hole they've disappeared to, and start putting their customers first.