LogRocket and Subtext: From a Signal to the 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.

This guide assumes the Subtext capture snippet is installed and the LogRocket SDK (logrocket) is initialized.

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.

const subtextUrl = FS('getSession', { format: 'url.now' })
if (subtextUrl) {
  LogRocket.identify(user.id, { subtext_url: subtextUrl })
}

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])

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.

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

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

Hand off to Subtext

For each readable URL, call review-open on the Subtext MCP:

review-open(session_url=<subtext_url>)     # Subtext MCP
# → Detect-vs-Diagnose: error/rage signal vs. user actually blocked

subtext_url only round-trips if it was attached at capture time (see 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.

Session Review overview — what your agent does once a session is open.
Install the capture snippet — required before any session URL exists to attach.

Get Started

Install by Framework

Session Review

Privacy

Integrations

Recipes

API reference

LogRocket and Subtext: From a Signal to the Session

Attach the session URL

On the user profile

On a specific event

From signal to session

For agents

​Attach the session URL

​On the user profile

​On a specific event

​From signal to session

​For agents

​Related

Attach the session URL

On the user profile

On a specific event

From signal to session

For agents

Related