How to track and resolve frontend errors using Smartlook event tracking

Ever had a bug report that just says, “It’s broken”? Yeah, not helpful. If you’re building or maintaining a web app, you know frontend errors are inevitable. The real trick is catching them before your users rage-quit and tracking down what actually happened. That’s where a tool like Smartlook can make your life easier. But only if you set it up right—and know what to pay attention to.

This guide is for frontend developers, QA folks, and product teams who want to stop guessing and start solving real frontend issues, without drowning in meaningless data.

Why bother tracking frontend errors?

Before you jump in, ask yourself: Do you really need another tracker? Most error monitoring tools (think Sentry, Bugsnag) catch stack traces and maybe give you a user session ID. But that’s only half the story. Frontend errors are messy—sometimes the cause is a weird user action, a flaky network, or a browser quirk.

Smartlook stands out because it records user sessions (think: video replays) and lets you track events and errors in context. You don’t just see “TypeError: Cannot read property ‘foo’ of undefined”—you see what the user did right before it blew up.

But fair warning: if you just want stack traces and don’t care about user context, Smartlook might be overkill. If, on the other hand, you want to see what really happened, keep reading.

Step 1: Set up Smartlook in your frontend project

Let’s keep this short and practical—no one wants to read a 10-step install guide.

1.1 Create a Smartlook account and project

  • Sign up for a free account on Smartlook.
  • Create a new project for your web app.
  • Grab the tracking code snippet from the dashboard.

1.2 Add the snippet to your app

  • Paste the Smartlook snippet into your HTML <head>, or load it dynamically in your JS entry point.
  • For React/Vue/Angular: Place it somewhere it runs once, like the main App component or a root layout file.

Pro tip: Don’t put it in a place where it’ll reload on every route change. You want one session per user visit.

1.3 Verify it’s working

  • Open your site, trigger a few page views, and check the Smartlook dashboard for new sessions.
  • If you don’t see anything, check your ad-blocker or browser privacy settings—they can block trackers.

Step 2: Capture frontend errors as custom events

Out of the box, Smartlook records sessions and some basic events (clicks, visits). But to track actual JS errors, you’ll need to wire it up yourself.

2.1 Listen for errors in your app

Add a global error handler. Here’s a plain JS version:

js window.addEventListener('error', function(event) { if (window.smartlook) { window.smartlook('track', 'frontend_error', { message: event.message, filename: event.filename, lineno: event.lineno, colno: event.colno, stack: event.error ? event.error.stack : null, }); } });

For frameworks:

  • React: Use an Error Boundary. In componentDidCatch, call smartlook('track', ...).
  • Vue: Use the global errorHandler.
  • Angular: Implement ErrorHandler and call smartlook('track', ...) inside.

2.2 Track unhandled promise rejections

Don’t miss these—they’re common and easy to overlook:

js window.addEventListener('unhandledrejection', function(event) { if (window.smartlook) { window.smartlook('track', 'unhandled_promise_rejection', { reason: event.reason ? event.reason.toString() : 'unknown', stack: event.reason && event.reason.stack ? event.reason.stack : null, }); } });

Pro tip: Don’t dump sensitive data (like user tokens) into error events. Keep it to error messages and context.

Step 3: Make errors actually useful with context

A raw error message is rarely enough. Here’s how to make your Smartlook events worth your future self’s time:

3.1 Add breadcrumbs

Add extra data to your events, like:

  • The current page or route
  • User ID (if available)
  • What the user was doing (e.g., “clicked submit”, “opened modal”)

Example:

js window.smartlook('track', 'frontend_error', { message: event.message, route: window.location.pathname, userId: window.myAppUserId || null, action: window.lastUserAction || null, });

3.2 Track user actions

Hook into your UI to record meaningful actions. For example:

js document.querySelector('#save-btn').addEventListener('click', function() { window.lastUserAction = 'clicked_save_button'; });

Now, when an error fires, you’ll see the last user action—way more helpful than just a stack trace.

Step 4: Find and analyze errors in Smartlook

Now the fun part—using the dashboard to actually fix stuff instead of just collecting data.

4.1 Filter sessions by error events

  • Go to the “Events” or “Analytics” section in Smartlook.
  • Filter for your custom error events (e.g., frontend_error, unhandled_promise_rejection).
  • You’ll see a list of sessions where errors happened.

4.2 Replay sessions to see what really happened

  • Click into a session with an error.
  • Watch the replay—see exactly what the user did leading to the error.
  • Pay attention to weird edge cases: rapid clicks, copy-paste, network dropouts.

4.3 Export or share errors with your team

Smartlook lets you share session links or export error details. Don’t just slap them in a ticket—add a human-readable note. “User clicked save twice fast, got 500 error.”

What works: Seeing the user’s journey is a game-changer for weird bugs.

What doesn’t: Don’t expect Smartlook to magically fix flaky stacktraces or obfuscated minified code. You’ll still need source maps for that.

Step 5: Don’t drown in noise—filter and prioritize

If you send every little warning as an event, you’ll quickly get alert fatigue. Here’s how to keep it useful:

  • Only track errors that matter. Ignore harmless console warnings or known quirks.
  • Deduplicate events—e.g., don’t spam the same error 100 times if it happens in a loop.
  • Set up alerts for high-impact errors: if a bug affects many users or blocks key flows, that’s worth your attention.

Pro tip: Review your tracked events every month or so. If you never act on a certain error, consider dropping it.

Step 6: Actually fix and verify the errors

This is the part a lot of teams skip—don’t just watch errors pile up.

  • Use Smartlook’s session replays to reproduce the issue locally.
  • Fix the bug in your codebase.
  • Deploy, then use Smartlook to confirm the error doesn’t show up in new sessions.

If it keeps happening—dig deeper. Sometimes the real root cause is a few steps earlier in the session.

Honest thoughts: Where Smartlook shines (and where it doesn’t)

What’s great:

  • Session replays give you eyes on the ground. No more guessing what users did.
  • Custom events let you track the errors you care about, not just generic “JS Error” blobs.
  • Filtering and sharing make it easier to triage and fix real issues.

Limitations to know:

  • Smartlook doesn’t magically decode minified stacktraces—set up source maps if you want readable errors.
  • It’s not a full-on error aggregator like Sentry. You won’t get detailed stack aggregation or alerting out of the box.
  • Privacy and compliance: You need to filter out sensitive data yourself, especially in error payloads and session replays.

Wrapping up: Keep it simple, iterate often

Front-end errors are going to happen. The key is catching them early, seeing what users actually did, and fixing what matters most. Smartlook is a solid tool for the job—if you set it up to track the right events and don’t drown yourself in data.

Start small: wire up the basics, track a few key errors, and see if the session replays actually help you squash bugs faster. Review what you’re tracking every so often, and don’t be afraid to turn off the noise.

Remember: the goal isn’t perfect error-free code—it’s making your users’ lives less frustrating, one bug at a time.