posthog/exporting-session-recordings
skills/exporting-session-recordings/SKILL.md
Export a single session recording's raw data (recording blocks + ClickHouse metadata) to a downloadable zip, and download it. Staff-only, via the django admin portal. Use when asked to "export a session recording", "get the raw recording data", "download a replay export", "pull a recording for analysis/support", or to inspect recording block / canvas frame sizes offline. Explains the team-ownership rule, how to build the admin export / download links for the owning team, and that there is no export or download API/MCP tool.
$ install --global
skillsauthnpx skillsauth add posthog/ai-plugin exporting-session-recordingsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 23, 2026, 6:56 AM87.0s1 file scanned
SKILL.md
- name:
- exporting-session-recordings
- description:
- >-
Exporting session recordings
Exporting bundles a recording's storage blocks plus its ClickHouse metadata
(events.json, session-replay-events.json) into a zip in object storage, for
offline analysis or support. It is staff-only and writes nothing back to the
recording.
There is no export API or MCP tool — a recording export is a cross-tenant, token/agent-reachable PII export, which is too dangerous to expose on the programmatic surface. Exporting (and downloading) is done only through the django admin portal, under interactive staff auth. Your job is to hand the user the right admin links.
The one rule that matters: export from the team that owns the recording
The export workflow fetches recording blocks and events filtered by the team you
run the export for (block storage is keyed by team; the events query filters
team_id). If you run it for the wrong team, the job still reaches
status: complete — but the zip is empty (zero blocks, empty events.json).
"Complete" means "the workflow ran", not "it found data".
So always export from the owning team's admin page. The owning team_id is
visible in the recording's storage path and in export_location
(session_recording_exports/<team_id>/<session_id>/<uuid>.zip).
Exporting via the admin portal (generate these links)
You need the owning team_id to build the links. If you only have a
session_id, get the team from the recording's project (or ask the user). Use the
correct region host — us.posthog.com or eu.posthog.com — matching where the
recording lives.
- Trigger the export (form takes
session_id+reason;reasonis audited):https://<region>.posthog.com/admin/posthog/team/<team_id>/export-replay/ - See exports + download buttons for that team:
https://<region>.posthog.com/admin/posthog/team/<team_id>/export-history/ - Direct download of one archive once
statusiscomplete:https://<region>.posthog.com/admin/posthog/team/<team_id>/download-export/<export_id>/
Hand the user the export-replay link to start it, then the export-history link to
poll status and download. A small recording takes seconds to a couple of minutes
(it gathers blocks plus ClickHouse metadata); the export-history page shows
pending / running / complete / failed.
Downloading the archive
The download view (export-history / download-export links above) streams the zip
straight from the replay-v2 S3 bucket as export-<session_id>.zip. export_location
is only a storage key, not a URL. The admin pod holds the prod credentials, so a
local dev or agent session cannot aws s3 cp the key itself — the user downloads
from the admin page in their browser.
Gotchas
- Empty-but-complete is the failure mode to watch for — see the team rule. If an archive is unexpectedly tiny, the export almost certainly ran from the wrong team's admin page.
- Expiry: exports older than 7 days report
is_expired: trueand their data may be purged. Re-export rather than relying on an old job. - Stuck
running: a failed export used to sit inrunningforever; a new export now reaps any export stillpending/runningpast ~48h tofailed, so old wedged rows clear themselves. Don't read a long-stalerunningas "still working". - Large recordings: multi-GB recordings (tab-left-open-for-days outliers) are not practical to export — the pipeline base64s every block through Redis and zero-pads to byte offsets on disk. Prefer recordings in the hundreds-of-MB range.
- Reason is audit-logged and surfaced in admin — write it for a human reviewer.
Related Skills
posthog/signals-scout-tasks
data-ai
VerifiedTrustedCommunity
Signals scout for PostHog Tasks, the agent work items a project runs. Two lenses: delivery health (runs failing, clustered by repository and error class, and retry storms) every run, and on a slower rotation demand (recurring asks across human-authored tasks that point at a product gap). Skips the scout fleet's own run rows.
65SKILL.mdUpdated Jul 29, 2026
posthog/signals-scout-conversations
devops
VerifiedTrustedCommunity
Signals scout for the PostHog Conversations (support inbox) product. Watches the `$conversation_*` ticket-lifecycle events for support-delivery regressions — SLA breach-rate steps, first-response latency blowouts, backlog inflow-vs-resolution imbalance, and channel / assignment concentration — and files each dated regression as a report. Complements the per-ticket product-feedback signals the emission pipeline already fires; does not re-surface individual ticket content.
65SKILL.mdUpdated Jul 29, 2026
posthog/setting-up-data-catalog
development
VerifiedTrustedCommunity
Populates and maintains a project's data catalog (semantic layer): canonical metrics, trust marks (certifications) on warehouse tables/views, and reviewed table relationships. Use when asked to set up / seed / bootstrap the data catalog or semantic layer, to catalog a project's metrics, to certify or deprecate data sources, to propose or review table joins, or to work through the proposal review queue. To *use* an existing catalog to answer a business-number question, see querying-posthog-data instead. Trigger terms: data catalog, semantic layer, canonical metric, certify table, deprecate source, relationship proposal, metric drift, review queue.
65SKILL.mdUpdated Jul 29, 2026
posthog/investigating-logs
tools
VerifiedTrustedCommunity
Investigate logs in a PostHog project: verify a service or deployment is healthy, explain an error spike, triage an incident, or understand what a log stream is saying. Use when the user asks to "check the logs", asks whether a service, deploy, release, or change is working or broke anything, asks why errors are up or what changed, or wants the root cause of failures visible in logs. Routes the logs MCP tools (services overview, pattern mining, before/after pattern diffing, bucketed counts, facets, raw rows) so investigations start from summaries instead of raw rows or hand-written SQL over the logs table.
65SKILL.mdUpdated Jul 29, 2026