How to Tell If a Website Uses LogRocket

LogRocket occupies a distinctive niche in front-end tooling: it combines session replay with error and performance monitoring, letting engineers watch a recording of exactly what a user did while also inspecting the JavaScript errors, network requests and application state behind it. That blend places it between qualitative tools like FullStory and developer tools like Sentry. The fastest way to detect it is to look for the cdn.logrocket.io SDK in the Network tab or to type LogRocket into the console. This guide covers every reliable signal, the SDK mechanics, the look-alikes, and what the find tells you.

What is LogRocket?

LogRocket is a front-end monitoring and product-analytics platform built for debugging real user experiences. It records pixel-accurate session replays, but unlike a pure replay tool it also captures the technical context an engineer needs: JavaScript errors and stack traces, network requests and responses, console logs, and application state (it has well-known integrations for Redux and other state libraries). When a user reports a bug, an engineer can open the exact session, watch what happened, and see the errors and network activity that accompanied it — turning "I can't reproduce it" into a concrete diagnosis.

For detection, the important framing is that LogRocket is used by product-and-engineering teams, especially on SaaS web applications where reproducing and fixing user-reported issues quickly is valuable. It is not a marketing tool; installing it requires a developer and a reason to care about front-end quality. So finding LogRocket signals a genuine application with an engineering team that takes the front-end experience seriously, and often a product organisation that blends qualitative observation with technical debugging. It also offers product-analytics features, so on some sites it doubles as the behavioural-analytics layer.

How LogRocket loads and sends data

A LogRocket install loads its SDK — from cdn.logrocket.io (with ingest on cdn.lr-ingest.io and related hosts) or bundled via the logrocket npm package — and initialises it with LogRocket.init('orgSlug/appId'), where the string identifies the organisation and application. The SDK then begins recording the session: it serialises the DOM and user interactions for replay, hooks into the browser's error and network APIs to capture diagnostics, and optionally integrates with the app's state management to log state changes.

That combined data streams to LogRocket's ingestion endpoints — r.logrocket.io and *.lr-ingest.io — continuously throughout the session, which is characteristic of a replay-plus-monitoring tool. The SDK exposes the global window.LogRocket object with methods including LogRocket.identify() (to attach a user identity to the session) and LogRocket.getSessionURL() (which returns a direct link to the current recording). Because the init string and the session URL both reveal the org and app, capturing either tells you precisely which LogRocket account is collecting the data. The init-then-stream pattern, with both replay and diagnostic data flowing to lr-ingest/logrocket.io, underpins all the detection signals.

How to tell if a website uses LogRocket

Confirm at least two of the following.

1. View the page source and bundles. Search for logrocket or LogRocket.init. Even bundled installs usually leave the LogRocket references and the orgSlug/appId init string in the application code.

2. Use the console. Type LogRocket and press Enter. A LogRocket page returns the global object exposing init, identify and getSessionURL. Running LogRocket.getSessionURL() returns a link to the current recording — definitive proof.

3. Check the Network tab. Filter for logrocket or lr-ingest. You will see the SDK load from cdn.logrocket.io and a continuous stream of session and event data to r.logrocket.io/*.lr-ingest.io. The ongoing requests are characteristic of replay-plus-monitoring.

4. Read the init string. Wherever you find LogRocket.init('orgSlug/appId'), the string identifies the organisation and application receiving the data.

5. Look for the npm package. A reference to the logrocket package (or framework plugins like logrocket-react) in the bundle confirms a bundled install.

What the LogRocket signals look like

LogRocket.init("acme-corp/web-app");
window.LogRocket = { init: ƒ, identify: ƒ, getSessionURL: ƒ, track: ƒ, ... }
GET  https://cdn.logrocket.io/LogRocket.min.js
POST https://r.logrocket.io/i/...   (streamed session + diagnostic data)

The combination of the window.LogRocket global, the cdn.logrocket.io SDK and streaming to r.logrocket.io/lr-ingest.io is conclusive, and getSessionURL() returning a link removes any doubt.

LogRocket versus similar tools — avoiding false positives

LogRocket straddles two categories, so it can be confused with both replay tools and error trackers. Against replay tools: FullStory uses edge.fullstory.com and the FS global, Hotjar uses static.hotjar.com and hj, while LogRocket uses cdn.logrocket.io and the LogRocket global. Against error trackers: Sentry uses window.Sentry and ingest.sentry.io, while LogRocket's distinctive feature is that it pairs the replay with error and network diagnostics in one tool. Confusion is unlikely once you see the LogRocket global or the logrocket.io hosts. As with all replay tools, the continuous ingest traffic is normal, and LogRocket can be loaded via a tag manager or bundled, so check the live page when the static source is inconclusive.

How reliable is each LogRocket signal?

A working LogRocket.getSessionURL() is definitive — it proves the SDK is live and recording. The window.LogRocket global, the cdn.logrocket.io SDK and streaming to lr-ingest.io/r.logrocket.io are all conclusive. The init('org/app') string is unambiguous and identifies the account. The weakest standalone signal is a stray "logrocket" mention with no global or ingest traffic. Because LogRocket records from the start of the session, you usually do not need to trigger an error to see activity — the LogRocket global plus ingest traffic confirms it immediately.

What a LogRocket install reveals about a company

LogRocket is a strong signal of a product-and-engineering organisation focused on front-end quality. Its combined replay-and-diagnostics approach is specifically chosen by teams that need to reproduce and fix user-reported bugs efficiently, so its presence marks a genuine web application with engineers who care about the user experience and have the tooling to debug it. The use of LogRocket.identify() indicates the team ties sessions to known users, common in authenticated SaaS products. If you sell developer tools, observability or QA products, customer-success software, or engineering services, a LogRocket install identifies a buyer who already invests in front-end quality and debugging. Because LogRocket also offers product analytics, finding it can mean the company uses one tool where others would deploy both a replay tool and an analytics platform — a consolidation signal worth noting.

LogRocket in a modern product stack

LogRocket typically sits within a SaaS product-engineering stack: a modern JavaScript framework (often React, given LogRocket's strong React and Redux integrations), an error-monitoring approach (sometimes LogRocket alone, sometimes alongside Sentry for broader coverage), and a product-analytics or support layer. Because LogRocket spans replay, diagnostics and analytics, it may reduce the number of separate tools a team needs. On the privacy side, a careful LogRocket deployment masks sensitive inputs and may gate recording behind consent, which is worth checking. For an auditor, the useful details are the org/app from the init string, whether identify is used, whether Sentry or another error tracker also runs, and which framework the front end uses; together these reveal how the company approaches front-end quality and where LogRocket fits among its tools.

A quick LogRocket confirmation walkthrough

Open the site with developer tools on the Console panel and type LogRocket — a returned object with init and getSessionURL confirms the SDK; run LogRocket.getSessionURL() for a link to your own session as definitive proof. Switch to the Network tab, filter for logrocket or lr-ingest, and watch the session data stream as you interact. In the Sources panel, search for LogRocket.init to read the org/app identifier. The window.LogRocket global plus a getSessionURL() result is conclusive, with the ingest traffic and init string as corroboration.

A quick LogRocket detection checklist

• Type LogRocket in the console and run LogRocket.getSessionURL() for definitive proof.
• Filter the Network tab for logrocket/lr-ingest; the SDK load and ingest stream confirm it.
• Search the bundles for LogRocket.init('org/app').
• Note any logrocket npm package or logrocket-react plugin.
• Check whether Sentry or another error tracker runs alongside it.
• Watch for LogRocket.identify() indicating user-level session tagging.

Detecting LogRocket at scale

One page is a quick console check, but scanning many domains for replay-plus-monitoring tools — to find product-led SaaS companies, say — needs automation. StackOptic detects LogRocket and thousands of other technologies from a real browser, catching bundled and tag-manager-injected installs. Running such a scan across a market segment quickly separates the genuine, engineering-led web applications from the brochure sites, because tools like LogRocket only appear where there is a real product and a team maintaining it. Re-scanning periodically also flags when a company adopts or drops front-end monitoring, a useful signal of shifting engineering priorities or budgets. For related reading, see checking what JavaScript libraries a website uses and the LogRocket technology profile.