Debug Hotjar in Chrome DevTools

What Hotjar traffic looks like

Hotjar splits its traffic across several hosts, each with a distinct job, and streams session capture over a WebSocket, not per-interaction beacons.

Endpoint pattern

Loader static.hotjar.com/c/hotjar-<siteId>.js?sv=<version> (the site ID is right in the URL); config from vars.hotjar.com (which pages to record, active heatmaps, sampling rates, feedback widgets); additional modules from script.hotjar.com; survey and feedback content from content.hotjar.io

Transport

Session capture streams over a WebSocket to ws.hotjar.com: you see the handshake, then nothing per-interaction; DOM mutations, mouse movement, and scroll data flow through the open socket. Identify calls, survey responses, and hj() API events go to in.hotjar.com and vc.hotjar.io as conventional requests

Cookies

_hjSessionUser_<siteId> and _hjSession_<siteId>: the site ID is encoded into the cookie name itself

Debugging Hotjar with Event Watcher

• No dedicated parser: the extension identifies each request by hostname, applies the Hotjar name and Session Replay category badge, and shows the raw request with parsed query and body parameters plus the Cookies section.
• That covers the questions that actually come up: which site ID is installed (read the loader URL), whether the vars.hotjar.com config fetch succeeded, whether a recording socket opened on a page that should be sampled, and whether _hjSessionUser_* cookies are set and sent.
• Grouping the stream by Endpoint separates the loader, config, ingestion, and survey hosts cleanly.

Hotjar and consent

Event Watcher checks Hotjar against the analytics consent category.

The consent-relevant moment is early: the loader and the vars.hotjar.com config fetch fire as soon as the snippet runs, and session capture can begin immediately after. Pre-consent requests are marked as violations.

Because recordings capture rendered pages, pre-consent capture is a heavier finding than a pre-consent pageview. Verify the snippet (or its tag-manager trigger) is gated on analytics, and confirm no _hjSession* cookies appear before the banner interaction.

Common debugging scenarios

• No recordings for a page. Confirm the static.hotjar.com/c/hotjar-<siteId>.js request fires there. If it does, check the vars.hotjar.com response context; the page may be excluded by targeting or lost to sampling.
• Wrong or duplicate site ID. The site ID is in both the loader URL and the cookie names. Two different IDs in one session means two snippets are installed.
• Recording starts before consent. Check the consent state on the first Hotjar events and watch for _hjSession* cookies pre-banner.
• Survey fires on the wrong audience. Watch content.hotjar.io and vc.hotjar.io requests to see when survey content loads and responses submit.
• Who added Hotjar? The Script Tree view attributes the loader to the site's own code, a tag manager, or a third-party script.