Rethinking front-end error reporting

#1

Post by jastr » Wed, Jan 17, 2018, 6:49 PM UTC

Rethinking front-end error reporting
blog.logrocket.com

Re: Rethinking front-end error reporting

#2

Post by ro-laren » Wed, Jan 17, 2018, 6:59 PM UTC

We built a similar system internally that accomplished some of these functions. Essentially data is ingested to an ELK cluster with some custom views on top. This definitely looks more polished though!

Re: Rethinking front-end error reporting

#3

Post by salt-licker » Wed, Jan 17, 2018, 7:19 PM UTC

I've used TrackJS in the past - they have context on the user session surrounding front-end exceptions, e.g. what the user clicked on beforehand. Is a video replay really that much more useful?

Re: Rethinking front-end error reporting

#4

Post by anarchy8 » Wed, Jan 17, 2018, 7:27 PM UTC

salt-licker wrote: post #3

I've used TrackJS in the past - they have context on the user session surrounding front-end exceptions, e.g. what the user clicked on beforehand. Is a video replay really that much more useful?

In my opinion yes -- being able to actually see the user going through the app before they clicked on the thing that made an error can make a huge difference. Sentry's breadcrumbs are similar, but they don't provide enough context. An actual session recording provide all the context.

Re: Rethinking front-end error reporting

#5

Post by yomielu » Wed, Jan 17, 2018, 7:43 PM UTC

I see this will log Redux actions/state leading up to a crash- can it also log data from MobX?

Re: Rethinking front-end error reporting

#6

Post by randall » Wed, Jan 17, 2018, 8:17 PM UTC

I feel weird... like I've never heard of this before and it seems fully built out... what am I missing?

Re: Rethinking front-end error reporting

#7

Post by bryanrasmussen » Wed, Jan 17, 2018, 8:22 PM UTC

So, 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?

Re: Rethinking front-end error reporting

#8

Post by simplify » Wed, Jan 17, 2018, 8:41 PM UTC

How does this compare to fullstory.com?

Re: Rethinking front-end error reporting

#9

Post by pkriete » Wed, Jan 17, 2018, 8:49 PM UTC

bryanrasmussen wrote: post #7

So, 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 frontend error reporting tools nowadays send a URL along with the exception and allow you to assign user data to the event.

Re: Rethinking front-end error reporting

#10

Post by arbesfeld » Wed, Jan 17, 2018, 8:51 PM UTC

simplify wrote: post #8

How does this compare to fullstory.com?

Good question- customers that have switched from FullStory generally say the logging is the reason they choose LogRocket. Network, console, and Redux logs gives support and developers crucial context for fixing bugs and understanding user issues.

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)