> ## Documentation Index
> Fetch the complete documentation index at: https://subtext.fullstory.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# LogRocket and Subtext: From a Signal to the Session

> Attach the Subtext session URL to LogRocket, then jump from any LogRocket signal — an error alert, a rage click, a hard-to-read replay — straight into the user's real session.

LogRocket flags that a session went wrong: an error fires, a user rage-clicks, a control goes dead. It gives you a replay you can scrub by hand, but it still makes you watch to find out *why*. Subtext turns that into a diagnosis. Attach the Subtext session URL to your LogRocket data and every LogRocket signal becomes a jumping-off point — your agent reads the `subtext_url`, opens that person's real session, and walks the decisive moments with screenshots, the component tree, network, and console. LogRocket detects; Subtext diagnoses.

<Note>
  This guide assumes the [Subtext capture snippet](/docs/install/overview) is installed and the LogRocket SDK (`logrocket`) is initialized.
</Note>

## Attach the session URL

Store the current Subtext session URL on your LogRocket data so it travels with the session. There are two places to attach it, depending on how precise the link needs to be.

### On the user profile

Attach the URL to the LogRocket user with `LogRocket.identify`. Call it wherever your app already identifies the user — on auth resolution, not at module top level.

<CodeGroup>
  ```js analytics.js theme={null}
  const subtextUrl = FS('getSession', { format: 'url.now' })
  if (subtextUrl) {
    LogRocket.identify(user.id, { subtext_url: subtextUrl })
  }
  ```

  ```tsx React theme={null}
  useEffect(() => {
    if (!user) return
    FS('setIdentity', { uid: user.id, properties: { email: user.email } })
    const subtextUrl = FS('getSession', { format: 'url.now' })
    if (subtextUrl) {
      LogRocket.identify(user.id, {
        name: user.name,
        email: user.email,
        subtext_url: subtextUrl,
      })
    }
  }, [user])
  ```
</CodeGroup>

### On a specific event

When the exact moment matters, attach the URL to a custom LogRocket event with `LogRocket.track`. `url.now` carries a timestamp, so the link opens the replay at that instant — ideal for high-signal moments like errors and conversion failures.

```js theme={null}
LogRocket.track('checkout_failed', {
  reason: error.message,
  subtext_url: FS('getSession', { format: 'url.now' }),
})
```

<Warning>
  Don't read `FS('getSession')` at module top level — it returns `null` until the session has started. Call `LogRocket.init` before `LogRocket.identify` — LogRocket's docs say to initialize as early on the page as possible and document `identify` as a post-init step. The session URL also changes on a new session and when `FS('setIdentity')` is called with a different `uid`, so re-call `LogRocket.identify` whenever you re-identify the user. And don't confuse the two replays: `subtext_url` points at the Subtext session, while `LogRocket.getSessionURL` points at the LogRocket recording — store both if you want round-trip linkage.
</Warning>

## From signal to session

LogRocket already gives you a replay you can scrub by hand. The Subtext review is the agent-driven read on top of it: paste the `subtext_url`, and your agent (with the Subtext MCP connected) runs `review-open`, steps through the matching session, and pulls screenshots, the component tree, network, and console at the key moments — then hands you a Detect-vs-Diagnose summary instead of asking you to watch the whole thing. However you first hear about a problem in LogRocket, the path is the same: get to the `subtext_url`, then hand it to your agent.

<AccordionGroup>
  <Accordion title="A LogRocket error-alert email">
    You're subscribed to the issue, and LogRocket emails you: *"New error affecting 23 sessions: `checkout_failed`."*

    Open the issue, pick an affected session, and open the identified user. Go to the **User Traits** panel and copy `subtext_url`.

    ```text theme={null}
    LogRocket flagged an error (`checkout_failed`) hitting ~23 sessions. Here's the matching Subtext
    session for one of them: <PASTE subtext_url>

    Open it and give me a Detect-vs-Diagnose read. Did the user actually fail to check out, or did
    the error fire under the hood while they succeeded? Walk the moments around the failure, show me
    the UI state and the failing request, and tell me if it reproduces. Summary I can paste into the
    LogRocket issue.
    ```
  </Accordion>

  <Accordion title="A rage-click or dead-click Slack alert">
    LogRocket posts a Slack alert about a session with rage clicks or a dead click on a key control.

    Open the flagged session, go to the identified user's traits panel, and copy `subtext_url`.

    ```text theme={null}
    LogRocket caught rage clicks in this session. Here's the Subtext session: <PASTE subtext_url>

    Find the moment the user started rage-clicking. What were they trying to do, what wasn't
    responding, and is the control actually broken or just slow/unclear? Tell me whether this is a
    bug or a design problem, and point me to the exact timestamp.
    ```
  </Accordion>

  <Accordion title="A LogRocket replay you can't read">
    You're already in a LogRocket session, scrubbing, and it's not obvious what went wrong.

    Grab `subtext_url` from the user's traits in that same session (store both replays at capture time so this round-trip always works).

    ```text theme={null}
    I'm looking at a LogRocket replay for user <USER_ID> and I can't tell what broke. Here's the
    matching Subtext session: <PASTE subtext_url>

    Cross-reference it: confirm whether the error visible in LogRocket reproduces, describe the UI
    state and the exact action sequence that triggered it, and tell me the one thing I should fix.
    ```
  </Accordion>
</AccordionGroup>

<Tip>
  After the review, paste the agent's summary back into the LogRocket issue so it carries a diagnosis, not just a replay link. Keep both links together — the `subtext_url` and the LogRocket session URL — so anyone can pick the read they prefer. For friction that spans several sessions — like an error hitting 23 of them — ask your agent to roll the findings into one proof document (`doc-create`) with a screenshot per session and a single shared link, then drop that link into the LogRocket issue. And if the review shows the error is cosmetic or self-recovering, mark the LogRocket issue accordingly: a thrown error is not a blocked user.
</Tip>

## For agents

An autonomous agent can drive the same loop against LogRocket — discover the friction, get to the `subtext_url`, and hand each session to the Subtext MCP — but LogRocket is the odd integration on both ends. There is no structured friction REST API (rage clicks, dead clicks, and error sessions are dashboard- and Galileo-only), and user traits are write-only over the API (the User Identification API `PUT .../users/<id>` *sets* traits, but there is no public GET to read them back). LogRocket does ship an official MCP server at `https://mcp.logrocket.com/mcp`, authenticated with OAuth or an API key as `Authorization: Bearer <token>`; no community server exists. Use it to *find* the friction session, but extract `subtext_url` from a store you can read back.

<Steps>
  <Step title="Discover who is affected">
    Call the LogRocket MCP's `find_sessions` or `use_logrocket` (natural-language via Galileo) — ask something like "sessions with rage clicks on /checkout in the last 24h" and get matching sessions back. This is the discovery step the REST API can't do. The Galileo Highlights API (`POST https://api.logrocket.com/v1/orgs/<org>/apps/<app>/highlights/`) exists but is user-scoped (`userID`/`userEmail` required), async, and capped at 10 recent sessions over 30 days — not a fleet-wide friction query.
  </Step>

  <Step title="Extract the session URL">
    There is no public read endpoint for LogRocket user traits, so read `subtext_url` from a store that captured it at the same time — a Sentry event tag, PostHog/Amplitude, or your warehouse. If LogRocket is your only store, fall back to the LogRocket session URL (from `find_sessions` or `LogRocket.getSessionURL`) and pair it with the Subtext session by hand.
  </Step>

  <Step title="Hand off to Subtext">
    For each readable URL, call `review-open` on the Subtext MCP:

    ```text theme={null}
    review-open(session_url=<subtext_url>)     # Subtext MCP
    # → Detect-vs-Diagnose: error/rage signal vs. user actually blocked
    ```
  </Step>
</Steps>

<Note>
  `subtext_url` only round-trips if it was attached at capture time (see [Attach the session URL](#attach-the-session-url)) and stored somewhere you can read back. Treat LogRocket as a discovery surface and a secondary replay, not the source of truth for the Subtext link.
</Note>

## Related

* [Session Review overview](/docs/session-review/overview) — what your agent does once a session is open.
* [Install the capture snippet](/docs/install/overview) — required before any session URL exists to attach.