How to set up performance monitoring dashboards in LogRocket for product teams

If you’re on a product team, you know the pain: users complain about “slowness,” but you can’t pin down what’s actually slow, who’s affected, or if it’s getting better. Or worse, your team drowns in vague metrics that nobody checks. This guide is for folks who want useful performance dashboards in LogRocket—not another pile of charts nobody reads.

Here’s how to set up dashboards that pull real signals from the noise, help you spot problems before users yell, and show your team what’s actually worth fixing.


What LogRocket Actually Does (and What It Doesn’t)

LogRocket is best known for session replay—watching what users did, see errors in context, that sort of thing. But it’s also got a solid set of performance monitoring tools: think page load times, slow network requests, JavaScript errors, and even Core Web Vitals.

What’s good:
- It ties performance issues to real user sessions—so you can see who’s actually affected, not just aggregate numbers. - You can filter by user segments, devices, browsers, or even release version. - Dashboards are shareable—no more “can you send me that screenshot?”

What’s not:
- It won’t replace a full-on APM (like New Relic or Datadog) if you need deep backend tracing. - The out-of-the-box dashboards are a bit generic. You’ll need to set up your own to get real value. - Can get noisy if you don’t set sane filters. Nobody wants 100 alerts a day.


Step 1: Get Your Data Flowing

Before you can build a dashboard, LogRocket needs to actually see your app in action.

1.1. Install LogRocket

If you haven’t already, you’ll need to add LogRocket to your frontend codebase. For most React, Vue, or vanilla JS apps, it’s a 2-minute install.

bash npm install --save logrocket

And in your main entry file: js import LogRocket from 'logrocket'; LogRocket.init('your-app-id/project');

  • Replace 'your-app-id/project' with your actual LogRocket ID.
  • For SPA frameworks, make sure you initialize after your router loads.

Pro tip:
Don’t put this in production until you’ve tested it in staging—you don’t want to accidentally record internal test data.

1.2. Verify Data Is Coming In

  • Log into LogRocket.
  • Open a session in your app (click around a bit).
  • Check the LogRocket dashboard for new sessions.

If you see your visit, you’re good.


Step 2: Decide What to Track—Don’t Track Everything

A dashboard is only as good as what you put on it. Here’s what’s actually worth tracking for most product teams:

  • Page load time: How long does it take for users to see content?
  • Slow network/API requests: Which endpoints are slow, and for whom?
  • JavaScript errors: Are any new bugs causing performance hits?
  • Core Web Vitals: Largest Contentful Paint, First Input Delay, Cumulative Layout Shift (Google’s basics for user-perceived speed).
  • Custom events: Things like “checkout started” or “image uploaded” can be tracked if they’re key to your UX.

Ignore:
- “Average” stats that mix all users together (outliers matter more). - Uptime monitoring (LogRocket is not a ping tool). - Backend-only metrics (use a dedicated tool for those).


Step 3: Build Your First Performance Dashboard

Now for the fun part—getting all those signals in one place.

3.1. Create a Dashboard

  • From the LogRocket sidebar, click Dashboards.
  • Hit New Dashboard.
  • Give it a name your team will actually understand, like “Performance: What Users Actually Feel”.

3.2. Add Key Widgets

A. Page Load Time (First Contentful Paint / Largest Contentful Paint)

  • Add a Core Web Vitals widget.
  • Filter by “LCP” or “FCP” as metric.
  • Group by browser or device if your team supports multiple environments.

B. Slow API Calls

  • Add a Network Request widget.
  • Set up a filter for requests taking longer than, say, 1 second.
  • Group by endpoint or status code.

Pro tip:
Don’t bother with every single API call—focus on the critical ones (login, search, checkout).

C. JavaScript Errors with Performance Tags

  • Add an Errors widget.
  • Filter by error type or add custom tags for performance (e.g., “timeout,” “unhandled rejection”).

D. Custom Events (Optional but Powerful)

If you want to track, say, “checkout completed” times:

js LogRocket.track('checkout_completed', { value: 1200 }); // 1200ms

  • Then, add a Custom Event widget to your dashboard.
  • Set thresholds to flag slow experiences.

E. User Segment Breakdown

  • Add a Segmentation widget (e.g., by country, device, or version).
  • This helps you spot if only mobile users or only people on slow networks are hurting.

3.3. Set Up Filters—Don’t Skip This

Nobody wants a dashboard full of irrelevant noise.

  • Exclude internal test users or IPs.
  • Filter out bots and crawlers.
  • Limit to production environment.

Step 4: Make It Actionable—Alerts, Sharing, and Ownership

Dashboards are useless if nobody acts on them. Here’s how to make yours stick:

4.1. Set Up Alerts—But Be Ruthless

  • Only set alerts for things you actually care about (e.g., LCP > 2.5s for more than 5% of users).
  • Route alerts to a dedicated Slack channel or team email—not everyone all the time.
  • Review alert rules monthly—don’t let alert fatigue creep in.

4.2. Share With the Right People

  • Give product managers, designers, and QA access to the dashboard.
  • Don’t just send screenshots—invite them so they can drill in and see session replays.

4.3. Assign Ownership

  • Every widget or alert should have an owner (engineering, product, etc.).
  • If something spikes, someone should know it’s their problem to dig into.

Step 5: Iterate—Don’t Let Dashboards Rot

The biggest mistake: setting up dashboards once and never looking at them again.

  • Review weekly: Do the metrics still matter? Is there new tech debt to track?
  • Cull unused widgets: If nobody’s looked at a chart in a month, kill it.
  • Add context: Use dashboard notes to explain spikes, releases, or investigations.

Pro tip:
Don’t obsess over “perfect” dashboards. Start simple—just a couple of widgets that answer your team’s most common questions. Add more if (and only if) you need them.


What to Watch Out For

  • Noise: Too many metrics = nobody cares. Less is more.
  • Vanity stats: Tracking “average load time” across everyone hides pain points. Focus on 90th/95th percentile and segments.
  • Blaming the tool: LogRocket won’t magically fix slow code or bad APIs. It helps you see what’s slow, but fixing is still up to you.

Keep It Simple—And Useful

Performance dashboards should help you spot and fix real problems, not just look pretty in a slide deck. Start with the basics: page loads, slow calls, bad errors. Make sure someone owns each metric. Update your dashboards as your product changes.

If you’re not sure what to track, ask: “If this number goes up, do we care? Will we change something?” If the answer’s no, leave it off.

Set up what you need, ignore the rest, and your team will actually use these dashboards—not just pretend to.