Telemetry, Error Reporting & Support
Last updated: August 2026 | Provider: Vibe Technologies, LLC
What telemetry we collect and why
We collect two categories of telemetry from the Extension: product analytics (Google Analytics 4, via a first-party endpoint) and error/crash reports (Sentry). Full detail on what is sent to each is in the Privacy Policy and the Subprocessors list. In summary:
- Analytics events: event names and low-cardinality properties, a pseudonymous client ID, a hashed user ID, and plan tier. For settings changes we send the setting key name, never its value. We use this to understand which features are used and to fix what is broken — not for advertising.
- Error reports: error messages, stack traces, browser/extension version. Session replay is disabled; cookies, request headers, and URLs are stripped/sanitized before sending.
Purpose: product analytics tells us which features people actually use, so we build the right things. Error reports let us find and fix crashes without waiting for a user to report them manually. Neither is used to build advertising profiles, and neither is sold.
How to opt out
Open the Extension, go to Settings → Product Analytics, and turn the toggle off. This flips the vibe.analytics.enabled storage key to false. That key is read as a hard gate before every analytics event is queued or sent — when it is off, no event leaves the browser, full stop. Analytics is on by default (an opt-out model, not opt-in); we are stating that plainly rather than implying otherwise.
Error reporting (Sentry) does not currently have its own opt-out toggle. lib/sentry-config.jsinitializes Sentry whenever a DSN is configured in the build, independent of the analytics toggle above. We are disclosing this as the current, unflattering fact rather than describing a control that does not exist. A dedicated error-reporting opt-out is tracked as follow-up work; until it ships, the only way to stop error reports is to disable the Extension itself. If this matters for your use case, email [email protected].
Honest history
Funnel/onboarding analytics events were silently absent from every build for roughly a month before being found and fixed. That means "what we collect" was not a settled internal fact for that period — the events we intended to send were not actually arriving. We are disclosing this rather than implying our analytics pipeline has always matched its design. The fix restored the intended event set; this page reflects what is sent today, verified against the current lib/analytics.tsconsent gate and event list, not the historical gap.
Support channel
[email protected] is our owned support channel. It is a real, monitored inbox: mail sent to it is routed by a Cloudflare Email Worker into our shared Chatwoot support desk, where a human (or an agent acting on a human's behalf) triages and replies.
Response target: we aim to send a first response within 1 business day (Monday–Friday, excluding US holidays). This is an operating target, not a contractual SLA — we do not currently offer paid-tier guaranteed response times or an enterprise support contract. If you need one, email us and we will discuss it as a custom agreement.
For account, billing, or refund requests, see the Refund & Cancellation Policy.
Wondering if something is down? Check live service status before reaching out — it is generated from the same automated health sweep our team is paged from.