Why is LogRocket not recording sessions in my Next.js app on Vercel?

By Ohad Krispin, founder of VibeRaven · LinkedIn

LogRocket records a session only in a browser where LogRocket.init(appId) runs with your app ID. Check LogRocket's own causes first: the monthly session quota, paused recording, a session limit, init removed from the app, or Conditional Recording set too strict. Then check the code. In Next.js, call init from a Client Component inside useEffect, because the logrocket package does nothing when there is no window: in a Node run, init() returned without an error and LogRocket.sessionURL stayed undefined. Read the app ID from a NEXT_PUBLIC_ variable, which Next.js inlines at build time, so add it in Vercel and redeploy. Reproduced with logrocket 12.4.0 on 2026-10-31.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Repository check

Check this in your repo

Find a LogRocket app ID the repo does not document

For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. When the code reads process.env.NEXT_PUBLIC_LOGROCKET_APP_ID and .env.example does not list it, it reports env_var_drift as a warning that names the variable, but it cannot see the variables set in your Vercel project, so it cannot tell whether the app ID is set there.

It is a repository check, not a live database test: it does not start your app or load LogRocket. It is advice, not a gate, and it exits with code 1 when it finds a blocker.

npx -y viberaven@1.7.1 check

What it printed on a fixture repo

On 2026-10-31 we ran it on a small Next.js fixture repo made for this page, not a customer repo, with logrocket 12.4.0, a Client Component that calls LogRocket.init(process.env.NEXT_PUBLIC_LOGROCKET_APP_ID) and an .env.example that listed only APP_NAME. The output is below, with the folder shortened to ~/notes-app. It printed no blocker, so the exit code was 0. The other warnings are general checks that say nothing about LogRocket.

$ npx -y viberaven@1.7.1 check

viberaven check · ~/notes-app

🟡 No Content-Security-Policy header  (missing_csp_header)
   No CSP header was found in next.config, middleware, or vercel.json. XSS on any page can reach every user session.
🟡 No error boundary  (missing_error_boundary)
   No error.tsx / ErrorBoundary component was detected. A single render error white-screens the whole app for real users.
🟡 Env vars used in code but missing from .env.example  (env_var_drift)
   Code reads 1 environment variable that .env.example does not document (NEXT_PUBLIC_LOGROCKET_APP_ID). Fresh clones, CI, and the production deploy can silently run without them.
⚪ No loading states  (missing_loading_state)
   No loading.tsx or skeleton components were detected. Slow data fetches will look like a frozen app.
⚪ Custom not-found page not detected  (missing_404_page)
   The detected paths contain no App Router not-found file or Pages Router 404 file. This is file-presence evidence, not verification of deployed 404 behavior or coverage across every route.

Verdict: ✅ no blockers, 3 warnings · score 65
Fix: viberaven fix · Details: ~/notes-app/.viberaven/agent-tasklist.md

Does LogRocket.init throw "window is not defined" on the server?

Not in logrocket 12.4.0. The package checks for window when it loads and, without one, hands back an object whose methods do nothing. So init, identify and track all return silently in Node, and the symptom is missing sessions, not an error. A "window is not defined" in your server log comes from other code that touches window. The LogRocket quickstart says init must be called client-side, not server-side.

typeof window: undefined
LogRocket.init("abc/def"): returned, no error
LogRocket.identify("u1"): returned, no error
LogRocket.sessionURL: undefined

Where do I call LogRocket.init in the Next.js App Router?

Layouts and pages are Server Components by default. The Next.js docs list lifecycle logic such as useEffect and browser-only APIs such as window as reasons to use a Client Component, and they say Client Components are also prerendered to HTML on the server. So put init in a file marked "use client", inside useEffect, and render that component once from the root layout. LogRocket's troubleshooting page adds that init must run before other code in the app, and that a site that is not a single-page app needs it on every page.

"use client";
import { useEffect } from "react";
import LogRocket from "logrocket";

export default function LogRocketInit() {
  useEffect(() => {
    const appId = process.env.NEXT_PUBLIC_LOGROCKET_APP_ID;
    if (!appId) {
      console.warn("LogRocket app ID is missing");
      return;
    }
    LogRocket.init(appId);
  }, []);
  return null;
}

Why does LogRocket record locally and not on my Vercel deployment?

Two causes show up with AI-built apps. First, the app ID: Next.js leaves a variable without the NEXT_PUBLIC_ prefix out of browser code, and inlines a prefixed one into the bundle at next build, so changing it in Vercel needs a new build. Write the name literally, because dynamic lookups such as process.env[name] are not inlined. In a Vite app the prefix is VITE_ and the value comes from import.meta.env. The init call itself throws nothing when the ID is undefined, so the failure is silent. Second, a condition: LogRocket's docs say to simply not call init during development, and that it records only sessions where init is called, so a wrong environment check around init turns recording off in production too.

Checklist

How to fix it, then check the fix

01
Find a LogRocket app ID the repo does not document. For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. When the code reads process.env.NEXT_PUBLIC_LOGROCKET_APP_ID and .env.example does not list it, it reports env_var_drift as a warning that names the variable, but it cannot see the variables set in your Vercel project, so it cannot tell whether the app ID is set there. It is a repository check, not a live database test: it does not start your app or load LogRocket.
```
npx -y viberaven@1.7.1 check
```
02In the LogRocket dashboard, rule out the causes its docs list: the monthly session quota, recording paused for the project, a session limit that was reached, and Conditional Recording conditions that are too strict. No code change fixes these.
03
Find every init call and the variable it reads, and check that init is not wrapped in a condition that is false in production:
```
grep -rnE "LogRocket.init|LOGROCKET" --exclude-dir=node_modules --exclude-dir=.next --exclude-dir=dist .
```
04Move init into a "use client" component, inside useEffect, rendered once from the root layout (or the entry file in a Vite app).
05
Add the app ID in Vercel for each environment that should record, and add the name with no value to .env.example:
```
vercel env add NEXT_PUBLIC_LOGROCKET_APP_ID production
vercel env add NEXT_PUBLIC_LOGROCKET_APP_ID preview
```
06
Redeploy, because a NEXT_PUBLIC_ value is fixed at build time. Open the deployment in a normal window, then run this in the browser console. A string means LogRocket loaded; null or undefined means it did not, and the console shows a warning if the script failed to load. Wait a few seconds after the page opens:
```
window.LogRocket && window.LogRocket.sessionURL
```

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Should I turn LogRocket off in development?

The LogRocket docs say to simply not call init() during development, for example behind a condition such as a check on who the user is. Keep the condition narrow and test it on the production build, because skipping init stops all recording in that environment.

My site is not a single-page app. Where does init go?

LogRocket's troubleshooting page says that on a site that is not a single-page app, init() must be called on every page, or sessions can end early.

Init runs and the console is quiet, but there are still no sessions. What next?

Look at the Network tab for the request that loads the LogRocket script. If the console shows "LogRocket: script could not load", something blocked it; a Content-Security-Policy that lacks LogRocket's hosts and a browser extension are two of the causes on LogRocket's troubleshooting page.