Privacy at RocketDebug
This page describes what data RocketDebug captures, where it goes, how long it stays, and which third parties touch it. It is rendered from our codebase so it cannot silently drift from reality.
Last updated: April 21, 2026
Our role
Processor of customer session data. RocketSupport is the data processor for customer session data — recordings (rrweb events), console logs, browser events, voice annotations and transcriptions, trigger events, AI analysis outputs, and any customer descriptions or context captured by the snippet. Our clients are the data controllers for that data: they decide when to record, configure masking rules, own the relationship with their end-users, and sign DPAs with their own customers.
Controller of admin identity data. RocketSupport is the data controller for admin identity data — the email addresses, display names, login sessions, membership records, audit logs, and password reset tokens that identify the admins who log in to RocketSupport itself. We make independent decisions about this data (authentication, security, billing) and are therefore its controller.
The snippet does not surface an end-user privacy notice; informing end-users is the client's responsibility.
Sub-processors
Third-party services that process data on our behalf.
- OpenAIUS
Runs the AI Recording Analysis pass (outcome classification, structured bug report, highlight detection) on redacted inputs.
Data:
console log messages (PII-redacted),browser event timeline,customer descriptions,voice transcriptions,trigger reason Stores recording artefacts (rrweb event streams, voice audio).
Data:
rrweb session JSON,voice audio (opus/webm)Primary relational store — projects, users, memberships, reports, recording metadata, analysis outputs, audit logs.
Data:
admin emails,membership audit log,report metadata,recording metadata,AI analysis outputsEphemeral session state — WebSocket session tracking, account-lockout counters, snippet-detection last-seen sets.
Data:
WebSocket session ids,login attempt counters (SHA-256 hashed email),snippet detection origins (10-minute TTL)- ResendUS
Sends password reset and admin invite emails via SMTP. Does not send marketing email. Retains email logs for 30 days (vendor default).
Data:
admin email addresses,email subject lines,email bodies (including one-time-token reset/invite links) Serves the dashboard and backend. Access logs are retained per the hosting provider's standard policy.
Data:
HTTP access logs,IP addresses of connecting clients
Data inventory
Every field captured or stored by the platform, classified.
Personal data
- Admin email addressPostgres `users` table · Until admin account is deleted
- Admin display namePostgres `users` table · Until admin account is deleted
- Admin password hash (bcrypt)Postgres `users` table · Until admin account is deleted
- Recording rrweb event stream (DOM + user interactions)S3 object storage + Postgres metadata · Configurable per project (1-730 days, default 90) masking applies
- Recording console logsPostgres `recordings` table · Configurable per project (1-730 days, default 90) masking applies
- Voice annotation audio filesS3 object storage · Configurable per project (1-730 days, default 90)
- Voice annotation transcriptions (when AI Analysis enabled)Postgres `recordings` table · Configurable per project (1-730 days, default 90) masking applies
- Customer-written issue descriptionPostgres `recordings` table · Configurable per project (1-730 days, default 90)
Operational
- Admin project memberships and rolesPostgres `agent_memberships` table · Until membership is revoked
- Membership lifecycle audit trailPostgres `membership_audit_log` table · Indefinite (compliance record)
- Password reset and invite tokens (SHA-256 hashed)Postgres `password_reset_tokens` table · Single-use; expires after 1 hour
- Failed-login counters (hashed email key)Redis (TTL 15 min) · 15 minutes from last failure
- Project namePostgres `projects` table · Project lifetime
- Project public key (used by the snippet to authenticate)Postgres `projects` table · Project lifetime
- Project privacy-masking rulesPostgres `projects` table · Project lifetime
- Per-project data retention setting (1-730 days, default 90)Postgres `projects` table · Project lifetime
- Report title and descriptionPostgres `reports` table · Configurable per project (1-730 days, default 90)
- Agent-written triage actions and overridesPostgres `reports` table · Configurable per project (1-730 days, default 90)
- AI analysis outputs (outcome classification, bug report, highlights)Postgres `recording_analyses` table · Configurable per project (1-730 days, default 90)
- AI analysis job metadata (input snapshot, cost, status)Postgres `ai_analysis_jobs` table · Configurable per project (1-730 days, default 90)
- Pattern alert aggregates (multi-recording clusters)Postgres `pattern_alerts` table · Configurable per project (1-730 days, default 90)
- Hosting-provider HTTP access logs (IP, path, status)Hosting provider log retention · Per hosting provider default (~30 days)
Telemetry
- Dashboard WebSocket session stateRedis (ephemeral) · Session lifetime (~24h)
- Browser event timeline (clicks, navigations, network errors)Postgres `recordings` table · Configurable per project (1-730 days, default 90) masking applies
- Browser metadata (user agent, viewport, locale)Postgres `recordings` table · Configurable per project (1-730 days, default 90)
- Trigger rule evaluation eventsPostgres `trigger_events` table · Configurable per project (1-730 days, default 90)
- Snippet-detection last-seen origins (Feature 008)Redis sorted set per project · 10-minute rolling window; 1-hour key TTL
Retention
Retention is configurable per project between 1 and 730 days. The default is 90 days. Clients can shorten or lengthen this window per their data-minimisation needs.
Data requests
How clients trigger deletion and export of data we hold on their behalf.
- Deletion. Client admins invoke the
POST /v1/data-deletionendpoint to delete a specific recording or all data for the project. End-user deletion requests route through the client (controller) to this endpoint. - Export. Self-serve export is not available in v1. Clients request an export by following the client-responsibility doc — we produce a per-project data bundle on request.
Not supported in v1
We believe transparency means listing what we don't do yet as clearly as what we do.
Formal Data Processing Agreement (DPA)
Not self-serve in v1. A DPA template with counsel sign-off is not published; contact the team if you need one.
Why deferred: Requires legal counsel review before publication.
EU data residency / regional deployment
Not supported in v1. All data is stored in US-region infrastructure. Contact the team if you need a custom EU deployment.
Why deferred: Architectural work (multi-region Postgres, object storage, Redis) is non-trivial and premature before first EU customer.
Self-serve right-to-erasure workflow
Not supported in v1. Erasure requests are handled by the existing `/v1/data-deletion` endpoint, which an admin invokes on the end-user's behalf. A self-serve UI that cascades through recordings, reports, analyses, audit logs, and backups is deferred.
Why deferred: Cascading deletion across every store (including backups) deserves its own spec.
SOC 2 / ISO 27001 / HIPAA BAA
Not certified in v1. RocketSupport has not completed SOC 2, ISO 27001, or a HIPAA Business Associate Agreement.
Why deferred: Organisational certification programmes — separate from product development.
Consent Management Platform (CMP) integration
Not supported in v1. The snippet does not integrate with third-party CMPs (OneTrust, Cookiebot, etc.).
Why deferred: The snippet fires only after an explicit customer "Report Issue" click; broader CMP integration is premature.