So anyone should ask, what is the GDPR impact here?
I believe we fall into the same categories as any other analytics tools (or any data controller/data processor in GDPR speak). Which is to say, there are compliance boxes that need to be checked (right to object, right to be forgotten, etc), but it's possible to be compliant and we plan to be when the law takes effect in May.
It's also worth noting that pretty much all frontend error reporting tools nowadays send a URL along with the exception and allow you to assign user data to the event.
Seems simpler to try really hard to keep the data anonymous.
There's no possible way to keep an app that can reconstruct screen state anonymous. The app, by necessity, records all info the user enters.
I'd be more concerned about PCI.
Doing open source well requires significant resources for community management, PR review, and support. When we do release an open source version of LogRocket, we want to be sure that we can dedicate enough time to supporting our users and engaging the community.
(I work at LogRocket)
The product is built-out in the sense that we have many customers who use LogRocket daily to fix bugs and support their users.
Of course we've only just started toward our long term goal and have lots more work to do!
At larger scale (10M+ sessions), LogRocket dynamically samples sessions to help surface the most important sessions and issues from your application. Hope that's helpful.
(disclosure: I work on LogRocket)
We think to do alerting correctly you really have to be sure that you're primarily flagging issues that actually impact the user. Nobody wants to get called in the middle of the night for a random browser quirk that didn't affect usability.
Definitely get in touch if you have something specific you need alerting on!
