I see this will log Redux actions/state leading up to a crash- can it also log data from MobX?
Yep! LogRocket also supports Vuex, @ngrx/store, and mobx-state-tree (both actions + state logging)
Rethinking front-end error reporting
11–20 of 29 posts
Re: Rethinking front-end error reporting
#12Very cool! Do you know if this product is currently HIPAA compliant or if there are plans to make it so in the future?
Re: Rethinking front-end error reporting
#13I feel weird... like I've never heard of this before and it seems fully built out... what am I missing?
(disclosure - I wrote this article and 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!
Re: Rethinking front-end error reporting
#14Very cool! Do you know if this product is currently HIPAA compliant or if there are plans to make it so in the future?
Thanks! Yep, LogRocket is HIPAA compliant though we usually suggest that clients scrub all PII before it leaves the client.
Re: Rethinking front-end error reporting
#15So, we've logged everything the user has done into logrocket, and given logrocket some way of uniquely identifying the user. So anyone should ask, what is the GDPR impact here?
Note: I work at LogRocket (and also a European) 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…
Not only the right to be forgotten - but also requiring real, informed consent, up front, that can be denied.
Seems simpler to try really hard to keep the data anonymous.
Re: Rethinking front-end error reporting
#16Does LogRocket easily hook up to PagerDuty?
Re: Rethinking front-end error reporting
#17Does LogRocket easily hook up to PagerDuty?
It doesn't yet, but we did build it with reporting/monitoring tools in mind (a Slack integration is part of the beta).
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!
Re: Rethinking front-end error reporting
#18Are you still planning on releasing an open source version of LogRocket, much like Sentry offers one?
Re: Rethinking front-end error reporting
#19Are you still planning on releasing an open source version of LogRocket, much like Sentry offers one?
In the long term, it's definitely something we plan to do. For now, we are prioritizing building new features and improving the core product.
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)
Re: Rethinking front-end error reporting
#20Earlier quoted context omitted.
Note: I work at LogRocket (and also a European) 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…
Not only the right to be forgotten - but also requiring real, informed consent, up front, that can be denied. Seems simpler to try really hard to keep the data anonymous.
I'd call it a legitimate interest (site development and debugging tools) and skip the consent. Simply say you must allow cookies and our debugging tool or don't use the site. Particularly with SPA or js framework heavy sites where more bugs occur only in the browser, this is simply a development tool. Now, if you were primarily a rails site that uses very little javascript, this would be a much more questionable call.
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.