Frequently asked questions

helixatom Remote JS Debugger is a browser dashboard for inspecting another live webpage in real time. Attach a client with a script tag or console snippet that shares your session key, then stream console logs, inspect API-style request events, run JavaScript in the selected tab, and manage saved functions.

No. There is no sign-up or login. You open the dashboard, use a session key, and connect a page. Saved functions stay in your browser storage on that device.

Enter or confirm a session key, press Connect, then open How to Connect? Choose HTML script tag, console IIFE, bookmarklet, or another inject method. Use the same session key on the page you want to debug. When the client appears under Active Clients, select it to watch logs.

A session key is a shared identifier that pairs the dashboard with one or more client pages. Anyone who knows the key and can reach the signaling service can attempt to join that session, so treat keys like temporary secrets and avoid putting them in public, long-lived URLs when debugging sensitive pages.

Yes when possible. The preferred path is a direct WebRTC peer connection between the dashboard and the client. We do not monitor or inspect that peer-to-peer debug traffic. A signaling WebSocket is used only to set up the connection. If WebRTC fails (for example a firewall, VPN, or strict NAT), the session can fall back to a WebSocket relay through our server so debugging can continue. Even on relay, we do not monitor or log the debug payload contents — the server only forwards messages between your dashboard and client.

Relay is the fallback when peer-to-peer WebRTC cannot complete — commonly when a firewall, VPN, or NAT blocks it, or when the browser has no usable WebRTC. While ICE is still negotiating, the dashboard shows a countdown to relay fallback. After fallback, you get a dismissable notice and a Relay badge. Try another network or disable VPN if you want a direct P2P path again.

Debug payloads are streamed for the live session and shown in your browser. By default the client also keeps a capped local buffer in that page’s memory (not on helixatom’s cloud) so you can load events from before the dashboard connected; the dashboard can soft-retain a disconnected client’s on-screen logs until you reload. These are not stored as a permanent cloud archive, and we do not monitor or retain those contents for inspection. On P2P they stay between peers; on relay they are forwarded ephemerally without content monitoring or logging. If you see performance issues from helixatom on the debugging client, turn off retainSessionLogs / data-retain-session-logs.

Saved functions are stored locally in your browser (IndexedDB when available, otherwise localStorage). You can also export and import .hatomf share files. Clearing site data for this origin removes locally saved functions.

Use a modern desktop browser such as Chrome, Edge, Firefox, or Safari. WebRTC is preferred; browsers without usable WebRTC may still connect via the WebSocket relay path.

You need a way to run the client snippet on that page (edit the page, inject via console, or use another tool you control). Only connect to pages you are authorized to inspect. Remote code execution runs in the selected client tab with that page’s privileges.

Confirm the dashboard and page use the exact same session key, that the SDK script loaded, and that Connect is active on the dashboard. Firewalls, corporate proxies, or blocked WebSockets can prevent signaling. If peers cannot negotiate WebRTC, wait for the relay fallback notice or try a different network.

Save a function in the dashboard, then export or share a .hatomf file. Teammates can import that file into their own browser’s local saved-functions store.

Yes. Step-by-step how-to guides live under /docs, covering connect flows, console filters, API inspection, remote code, saved functions, and common workflows.