Privacy policy
What we collect, why, who else sees it, and how long we keep it. Every statement here was checked against the code that does it.
Two kinds of data, two roles
Your account. The details of the people who use Bugwatch: email address, sign-in, organization membership, billing. For this we decide what is collected and why, so we are the controller.
What you send us. The errors, transactions, sessions and check results your applications send to Bugwatch. These can contain data about your own users. We process it only to provide the service to you, on your instructions, so you are the controller and we are your processor. If you are one of our customers' users, ask that customer about their data; we will help them answer you.
What we collect about you
- Account: email address, name and avatar (if your sign-in provider gives us one), a password hash if you set a password (PBKDF2; we never store the password), when you confirmed your email, when you last signed in.
- Sign-in providers: if you continue with Google, GitHub or Microsoft, the provider's id for you and the email it reports. Their access token is used once and not kept.
- Organizations: the organizations you belong to and your role in each.
- Sessions: a random session id in a cookie. We store only its hash, and we do not record your IP address or browser against it.
- Billing: the payment provider's customer and subscription references. Card details go to the payment provider and never reach us.
- On-call: devices you register for push notifications (platform, device name, app version, push token), phone numbers you add to voice channels, your notification preferences and quiet hours, and on-call schedules.
- Activity: API tokens (stored as hashes), and an audit trail of changes made by people and agents in your organization.
What your applications send us
Error events, performance transactions, release health sessions and uptime check results, and files your SDK attaches to an event (such as a screenshot or a log), which are stored with that event and deleted with it. Profiles, session replays and user feedback are counted and then discarded; we do not store them.
Scrubbing. Before an event is processed into the record we keep, fields that look like secrets (passwords, tokens, API keys, authorization headers, cookies, card fields) become [Filtered], as do card numbers that pass a checksum and private-key blocks. Your application's user.ip_address is removed unless you turn on IP storage for the project. How scrubbing works.
Before scrubbing. So that nothing your application sends is lost if processing fails, we first store each request exactly as received, then process it. That raw copy is deleted after 7 days. Scrub sensitive data in your SDK as well if it must never be stored at all.
Analytics. Charts are built from a sampled index that holds ids, low-cardinality fields such as release and environment, the country a request came from, and a one-way hash of your user's id (salted per project). It does not hold names, emails or IP addresses.
Uptime checks send requests to the URLs you configure, with any credentials or headers you set for them. Those are stored encrypted, used only to run the check, and never returned by the API.
Status pages. People who subscribe to one of your status pages give us an email address (confirmed by a link) or a webhook URL (confirmed by a challenge). Unsubscribing deletes it.
How we use it
- To run the service: store and show your data, group errors, run checks, page whoever is on call.
- To send email you need: sign-in links, confirmations, alerts and notices.
- To bill organizations on paid plans and enforce plan limits.
- To keep the service safe: rate limits, abuse prevention and investigating security problems. Rate limits count requests per IP address; the counters for registering MCP clients keep the IP address for 2 hours.
We do not sell data, we do not use it for advertising, and we do not train AI models on it. The marketing site and dashboard run no analytics or tracking scripts, and our fonts are served from our own domain.
AI features
When someone in your organization asks the fix agent for a fix, or uses chat in the mobile app, the issue's context is sent to the AI model provider they chose (Anthropic, OpenAI or Google): the issue title, the exception, stack frames with the surrounding source lines, recent breadcrumbs and the release. If you connected a repository, the files the agent reads go too. Nothing is sent to a model provider unless a person runs one of these features.
How long we keep it
- Raw requests, before scrubbing
- Kept for7 days
- Error events and transactions
- Kept for30 days on the Free plan, 90 days on paid plans (set when the event arrives)
- Attachments sent with an event
- Kept forAs long as the event they came with
- Sampled analytics index
- Kept forUp to 3 months
- Daily issue statistics
- Kept for400 days
- Uptime results and incident timelines
- Kept for90 days
- Alert delivery records
- Kept for30 days
- Sessions
- Kept for30 days
- Sign-in links
- Kept for15 minutes; email confirmation links 24 hours
- Operational logs (held by Cloudflare)
- Kept forUp to 7 days
- Account, organization and configuration
- Kept forUntil deleted (see below)
| Data | Kept for |
|---|---|
| Raw requests, before scrubbing | 7 days |
| Error events and transactions | 30 days on the Free plan, 90 days on paid plans (set when the event arrives) |
| Attachments sent with an event | As long as the event they came with |
| Sampled analytics index | Up to 3 months |
| Daily issue statistics | 400 days |
| Uptime results and incident timelines | 90 days |
| Alert delivery records | 30 days |
| Sessions | 30 days |
| Sign-in links | 15 minutes; email confirmation links 24 hours |
| Operational logs (held by Cloudflare) | Up to 7 days |
| Account, organization and configuration | Until deleted (see below) |
Where it is processed
On Cloudflare's global network, which serves each request from a data center near where it came from. Data is not pinned to a region today, and we do not yet offer EU data residency. Transfers out of the EU and UK rely on our providers' Standard Contractual Clauses and the EU–US Data Privacy Framework where they participate in it.
Your rights, and deleting your data
You can ask us for a copy of your data, to correct it, or to delete it, and you can object to how we use it. Email privacy@bugwatch.io from the address on your account. We answer within 30 days. You may also complain to your data protection authority.
An organization's owner can delete it in Settings → General. It is gone at once, and its events, files and settings are erased within a few hours. You can delete your own account in Settings → Your account (if you own an organization, delete it or have it handed over first). Owners and admins can download the organization's data, its events and its transactions as JSON in Settings → General → Export, or over the API.
You can already remove members, revoke tokens and devices, delete channels, monitors and status pages, and turn IP storage off, yourself.
Security
How we protect data, from hashing secrets to signing webhooks, is described in Security and privacy. Report a vulnerability to security@bugwatch.io.
Children, and changes to this policy
Bugwatch is a tool for software teams and is not directed at children under 16.
We date every version of this policy. If a change matters, we email organization owners before it takes effect.