Debugging local session replay
When a developer says "local replay isn't working" or "recordings aren't showing up", work through these layers in order. The local replay pipeline has several moving parts and failures are usually silent.
Quick symptom guide
The local replay pipeline
A break at any point in this chain means no recordings in the UI. The diagnostic approach is to find where the chain breaks.
Step 1 — Is the SDK even trying to record?
Ask the developer to open browser DevTools Network tab and filter for /s.
If no /s calls at all:
The SDK isn't attempting to send recording data. Investigate client-side causes:
- Triggers configured in project settings. If URL triggers, event triggers, or linked flag triggers are set up, recording won't start until a trigger fires. This is the most common cause for developers who've been testing trigger features. Check Session replay settings in the local UI (Project settings > Session replay). Remove or adjust triggers to allow recording to start.
- Recording disabled in project settings. Session replay may be toggled off.
- Sample rate set too low. If
$replay_sample_rateis < 1.0, sessions may be sampled out. - SDK not initialized with recording. Check the local app's PostHog initialization —
session_recordingmust not be explicitly disabled. - Wrong PostHog host. The local app must point to
http://localhost:8000(or wherever the local Caddy proxy is running). - Ad blocker. Even in local dev, browser extensions can block the recorder script or
/sendpoint. - Recorder script failed to load (MIME type / CORS error). The browser console may show
MIME type ('text/html') is not executableforposthog-recorder.jsor a CORS error forlazy-recorder.js. This means Django is serving an HTML page (usually the login redirect) instead of the JS file — the static recorder scripts are stale or missing. See recorder script build failure.
If /s calls are happening with 200 responses:
The SDK is recording and capture is receiving data. The break is downstream — proceed to Step 2.
If /s calls are returning errors (4xx/5xx):
The capture service may be down or misconfigured. Check capture-replay in phrocs.
Step 2 — Are the required processes running?
Check that these phrocs processes are running and healthy.
A "running" process that never produced output after tsx watch src/index.ts is effectively dead.
Key processes and their ports
Verify with:
If ports are not listening: The processes haven't started or are stuck. See common failures.
If ports are listening: The pipeline processes are running. Proceed to Step 3.
Docker dependencies
These Docker containers must be running and healthy:
Check with:
All should show (healthy) except seaweedfs which doesn't have a health check.
If seaweedfs-main is missing, the replay Docker profile may not be active —
check the docker-compose phrocs process output for --profile replay.
Step 3 — Is data flowing through Kafka?
If capture-replay is running and receiving /s calls, data should land on the
session_recording_snapshot_item_events Kafka topic. Check the Kafka UI at
http://localhost:8080 (if the debug_tools intent is enabled) or use kcat:
If the topic is empty or doesn't exist: capture-replay isn't writing to Kafka. Check its phrocs logs for Kafka connection errors.
If data is on the topic but recordings don't appear: ingestion-sessionreplay isn't consuming. Check if it's stuck, crashed, or if an orphaned process is holding the consumer group (see common failures).
Step 4 — Check SeaweedFS
Ingestion writes recording blobs to SeaweedFS. Verify it's accessible:
The SESSION_RECORDING_V2_S3_ENDPOINT env var must be set correctly.
In bin/start, this defaults to http://seaweedfs:8333 (the Docker hostname).
Host processes resolve this via Docker networking.
Common failures reference
See common failures for detailed diagnosis of:
- Orphaned Node processes holding Kafka consumer groups
- Processes stuck at
bin/wait-for-docker - tsx watch silently swallowing crashes
- Port conflicts between Docker and host processes
- Cargo build lock contention on startup
