3 ms·

I think we see "frontend monitoring" in two different buckets: "metrics-oriented" and "incident-oriented". Metrics are about things like lighthouse scores, opti

I think we see "frontend monitoring" in two different buckets: "metrics-oriented" and "incident-oriented". Metrics are about things like lighthouse scores, optimizing your frontend bundle, etc.. which tend to only become relevant for larger companies as only at that point do these things affect conversions to a significant level. Incidents, however, are more about one-off issues happening in your web app, and that' what we're focusing on at highlight.io (at least right now). Examples include customer support issues, bugs that affect a user's experience, etc.. Both are important for larger companies, but for smaller companies, the only thing that we see as relevant are frontend "incidents". So to answer your question, I'd ask yourself what types of issues are you trying to track down? Does that make sense?

codethief 4y ago
My question was more about the error/incident monitoring part. For us the biggest challenges in this area have been 1) grouping errors correctly. Often, identical errors are not logged because the browser messes up the stack trace, because error messages are not completely identical (browser-dependent), or because the stack trace (line numbers etc.) have slightly changed from one version to another. So we often need to group errors by hand. 2) identifying what the impact of an error is. Is it critical? Is it enough if we look into it next week? Is it relevant at all? Add to that that our web shop sees a significant number of automated interactions by resellers, so errors due to broken browser extensions, their bots doing crazy things etc. have been quite common and often need to be ignored by hand. I really hope session replays are going to help us with 2).