Privacy Policy

BugJar (“we”, “us”) builds a privacy-first bug-reporting tool that customer engineering teams embed in their own products. This policy explains what data we handle, why, and how we protect it.

1. Roles

For the dashboard, billing, and account data we collect from our customers (engineering teams using BugJar), we act as a data controller.

For the bug-report content (DOM replays, voice, screenshots, console logs, network logs) our customers' end users submit through the SDK, we act as a data processor on behalf of our customer. The customer's own privacy notice governs that data; data-processing terms are available on request to enterprise customers.

2. Data we collect from customers

• Account. Name, work email, team name. Required to sign in.
• Authentication. Email-based one-time codes; optional Google OAuth identifier; optional TOTP secret. We never store passwords because we don't use them.
• Billing. Stripe customer ID, subscription state, plan tier. Card data is held by Stripe, never by us.
• Usage. Audit log entries (which user did what, from which IP), report counts, login events.

3. Data our customers route through us

When a customer's end user submits a bug report through the BugJar SDK, the report blob (DOM replay, audio, screenshot, attachments) is uploaded directly from the user's browser to Cloudflare R2 storage via presigned URLs. The application server we operate does not see the report content in transit. Metadata (timestamps, sizes, project ID, optional user identifier from a customer-signed JWT) is stored in our database.

Before transmission, the SDK applies redaction to the report client-side, masking passwords, API keys, payment card patterns, JWTs, authorization headers, and 17 default sensitive-pattern categories total. Customer staff reviewing reports in the dashboard see the redacted version; we do not see a less-redacted copy.

4. Where data is stored

• Report blobs (replay video, audio, screenshots). Cloudflare R2, US region. Uploaded directly from the customer's browser via presigned URL, so our application servers do not see the blob in transit. EU residency is on the roadmap; contact us for current options.
• Application database (metadata, accounts, audit log). Postgres, US region.
• Transactional email (login codes, billing receipts). A US-based transactional email provider. We rotate providers occasionally; the current one is named in our DPA.

5. Cookies and similar storage

BugJar sets only the cookies necessary to deliver the service. No analytics cookies, no tracking pixels, no advertising identifiers, no third-party scripts that set cookies on your behalf. The marketing site you are reading this on, the dashboard at dashboard.bugjar.app, and the SDK that runs on our customers' sites all follow the same rule.

The cookies we do set, on this marketing site:

• Laravel session cookie. Maintains your session across pages while you read or submit a form. HTTP-only, Secure, SameSite=Lax. Expires at the end of your browser session (or after 2 hours of idle, whichever is sooner).
• XSRF-TOKEN cookie. Anti-CSRF defense. Verifies that form submissions came from a page on our site. HTTP-only, Secure, SameSite=Lax.

Both are strictly necessary in the GDPR and ePrivacy Directive sense. They are required to deliver the service you are actively using, not for measurement or marketing, and are exempt from the cookie-consent requirement on that basis.

The dashboard at dashboard.bugjar.app sets the same two cookies, plus a sign-in cookie (auth_request_id) used to complete the passwordless login flow across browser tabs. All three are strictly necessary; none are analytics.

The BugJar SDK that loads on our customers' websites sets no cookies and writes no persistent storage on the dormant trigger. On init() the SDK does read localStorage once to check whether a previous page-load left a partial recording behind (and clears the entry if it's stale); on a fresh install that read finds nothing and nothing gets written. Until your end user clicks the trigger, the SDK is just an in-page button plus passive console + fetch wrappers that do nothing with the entries they observe — they only begin storing in an in-memory buffer once recording is active. Once the user clicks Record, the SDK writes partial-recording state to localStorage and IndexedDB so the recording survives a page reload — the user can finish what they started instead of losing the bug they were demonstrating. That storage is cleared once the recording is submitted or the user cancels.

We don't currently use any analytics service. If we ever add one, we will use a cookie-free option (such as Plausible or self-hosted Umami) and update this section before turning it on.

6. Retention

Report blobs and metadata are retained for the customer's plan period (Free: 30 days, Credit pack: 90 days, Solo: 6 months, Team: 2 years). At the end of the retention window, blobs are deleted from R2 by lifecycle rule and rows are purged from our database.

Account and audit data are retained for the lifetime of the account plus 30 days after deletion (the soft-delete window during which an accidentally-deleted account can be restored).

7. Sharing

We do not sell or rent personal data. We share data with our subprocessors (currently: Cloudflare, Stripe, our email provider, our error-monitoring provider, our hosting provider). We disclose data only when required by valid legal process, and we will notify the customer first unless prohibited.

8. Your choices

• Access / export. Sign in and use Account → Export, or email [email protected].
• Deletion. Use Account → Delete account. We hold the deletion for 30 days in case you change your mind, then we hard-delete.
• Correction. Edit your profile from the dashboard or contact us.
• End-user data subject requests. If you are an end user whose data was submitted via a customer's SDK installation, the customer is the controller for that data and we encourage you to contact them first. If you can't reach them, or you want a direct path, email [email protected] with the site/customer you submitted on and an identifier we can match (the email you used, an opaque user_id from the customer if one was shown, or the approximate date / page URL). Verified requests are honored within 30 days, the receiving customer's audit log records the action against their data.

9. Security

Most security policies open with a list of certifications. Ours opens with the architecture. The certifications follow from the design, not the other way around.

• Consent-gated capture. Recording is dormant until the end user clicks the BugJar trigger and explicitly opts in. No always-on capture, no background buffering of content.
• Browser-side redaction. Passwords, payment-card data, JWTs, API keys, authorization headers, and private keys are always masked, in the user's browser, before any byte leaves their device. Some categories have no override even for support flows.
• Direct-to-storage uploads. Report content moves from the end user's browser to Cloudflare R2 via short-lived presigned URLs. Our application servers never see the blob in transit and never have it at rest.
• Admin lockout. Our own admin staff cannot view a customer's report content. The endpoint that issues presigned GET URLs hard-rejects admin-guard sessions; every rejected attempt is recorded in the customer's audit log. The block is enforced in code, the rejection is visible to the customer, not just stated in this policy.
• Customer-readable audit log. Entries about what our staff accessed are visible to the customer in the dashboard. We cannot redact those entries.

Standard transport and storage measures (TLS for traffic, encryption at rest, scoped sessions, encrypted integration tokens) apply across the service. They're not what makes us different.

10. Changes

We will notify the customer's account email of material changes 30 days before they take effect. Continued use after the effective date constitutes acceptance.

11. Contact

Questions, requests, or data-protection issues: [email protected].