This document is not yet in force. Cluebase is not incorporated at the time of writing, so the legal entity, registered address and governing law are marked below as pending rather than stated. Everything else describes how the service actually operates today. This notice is removed when those three values are filled in.
1. Who we are
Cluebase (“Cluebase”, “we”, “us”) provides error recovery software. When an application breaks, our SDK captures the failure and opens a conversation with the person it broke on, then hands their team the resulting incident.
Our registered entity and address are pending incorporation. We can be reached at hello@cluebase.dev.
This policy covers two different groups of people, and the distinction between them decides almost everything that follows.
1.1 Customers, where we are the controller
A Customer is a developer or company that has a Cluebase account and installs our SDK in their application. For account data, billing data and dashboard usage, we decide why and how that data is processed, so we act as the data controller. Requests about that data come to us directly.
1.2 End users, where we are the processor
An End Useris a person using a Customer’s application when something breaks there. We process their data only on the Customer’s instructions and only to deliver the service the Customer configured, so for that data we act as a data processor and the Customer is the controller.
If you are an End User, your relationship is with the company whose application you were using. Their privacy policy governs what happens to your data, and a deletion or access request is answered by them. We will support them in answering it, and if you contact us directly we will pass your request to them and tell you we have done so.
Customers can action an erasure themselves, without waiting on us. The dashboard erases every conversation and all contact details held for one of their End Users, and the same operation is available to their own systems through our API.
2. Data we collect
2.1 Customer account data
- Identity and contact: name, email address, and authentication metadata, handled by our identity provider.
- Billing: subscription plan, billing contact, and payment records. Card details are handled by our payment processor and are never stored on our systems.
- Project configuration: project and product names, support email address, widget theme, allowed origins, notification settings, and API keys.
- Dashboard usage: pages viewed, features used, and API requests, so we can tell which parts of the product are working.
- Support correspondence: what you write to us, and our replies.
2.2 Incident data, captured from a Customer's application
This is the data our SDK sends when an application fails. It is End User data, processed on the Customer’s behalf.
- The failure itself: error name, error message, stack trace, and component stack.
- Where it happened: the page path or URL, and the browser and operating system reported by the user agent.
- A visitor identifier, generated by the SDK, used to group repeat failures for the same person and to apply rate limits.
- IP address, used for rate limiting, origin checks and abuse prevention. It is not used to build a profile of the End User.
2.3 Conversation data, given to us by the End User
When the recovery agent opens, whatever the End User chooses to type is processed. Nothing in this category is read off the page, taken from a form, or inferred without them typing it.
- The full transcript of the conversation, both sides of it.
- An email address, and a name, only where the End User types them in response to the agent asking.
- A short summary of what the End User was trying to do, in their own words.
- A read on their sentiment at the start and end of the conversation, and whether the conversation resolved, so the Customer knows who to follow up with first.
2.4 Identity data, supplied by the Customer
A Customer may tell us who their signed-in End User is, so the recovery agent does not have to ask for details their own application already holds. This is optional, off unless the Customer implements it, and supplied by the Customer rather than collected by us.
- The Customer's own identifier for that End User, which is also the key a deletion request is answered against.
- An email address and a name, where the Customer chooses to send them. Neither is required.
- A small set of flat key and value pairs the Customer attaches, such as a plan name. Nested data is rejected.
We never infer any of this. The SDK does not read local or session storage, does not read cookies, does not decode tokens, does not scan the page for text that looks like an email address, and does not read the values of form fields. If the Customer does not send it and the End User does not type it, the incident is anonymous. A Customer can also disable this category outright, in which case it is discarded in the browser before any request is made.
2.5 Website data
On our own marketing site and documentation we collect standard server logs and the cookie categories described in section 9.
3. How we use data
3.1 To provide the service
- Capturing, de-duplicating and grouping errors so a Customer sees one recurring problem rather than a thousand identical reports.
- Generating the recovery conversation an End User has when something breaks, and passing the resulting incident to the Customer.
- Delivering notifications to the channels a Customer connected, such as Slack, Telegram or a webhook.
- Producing the summaries, outcome classifications and draft follow-up messages a Customer reads in the dashboard.
- Authenticating Customers, enforcing plan limits, and billing.
3.2 To keep the service safe and available
- Rate limiting, origin verification, and detecting abuse of the ingest and conversation endpoints.
- Redacting credentials and payment details from captured error text before it is stored or sent onward (section 4).
- Investigating incidents affecting the service, and maintaining audit records of privileged actions.
3.3 To improve the product
We look at aggregate usage to decide what to build and where the product is failing. We do not read Customer incident data or End User transcripts for product research, and we do not use either to train machine learning models. See section 6.
3.4 To communicate with you
Customers receive service messages such as incident notifications, billing receipts and security notices, which cannot be turned off while an account is open. Product announcements are separate and can be turned off at any time.
4. What we never receive
The strongest privacy guarantee available is not collecting something in the first place, so two categories are removed before they can reach us, in two independent places.
- In the browser. Our SDK scrubs credentials and payment details out of captured error text before any request leaves the page, so no request carrying them is made.
- On ingest. A second pass runs on our servers on everything stored or sent onward, matching authorization headers, session cookies, JSON web tokens, provider API keys, and card numbers validated by checksum rather than guessed at by length. A Customer running an old SDK build is still covered by this one.
- In conversation. If an End User types something that looks like a password, a card number or a one-time code, the agent is instructed to tell them to stop and not to repeat it back, and the message is stored as a redaction placeholder rather than as its content.
We also never receive your application’s database, your source code, or any credential you have not put into an error message. Cluebase does not connect to your data stores.
5. Legal bases for processing
Where the GDPR, the UK GDPR, or an equivalent regime applies, we rely on the following legal bases. Where we act as a processor (section 1.2), the Customer is responsible for establishing a legal basis for the processing they instruct.
| Processing | Legal basis | Our role |
|---|---|---|
| Providing the service to a Customer | Contract performance | Controller |
| Capturing errors and running recovery conversations | Controller's legitimate interest, established by the Customer | Processor |
| Billing and account administration | Contract performance; Legal obligation | Controller |
| Rate limiting, abuse prevention and security | Legitimate interest | Controller and processor |
| Aggregate product analytics | Legitimate interest | Controller |
| Product announcements | Legitimate interest; Consent where required | Controller |
| Non-essential cookies | Consent | Controller |
| Responding to lawful requests | Legal obligation | Controller and processor |
6. AI processing
The recovery agent is a large language model, and this section says plainly what that means for the data involved, because it is the part of this product a reviewer should ask about first.
6.1 What is sent to a model
To generate each reply, the error context and the conversation so far are sent to a third-party model provider through an inference gateway. Both are named in the subprocessor register. The content sent has already passed through the redaction described in section 4.
6.2 What models are not used for
Data sent for inference is processed to answer that request and is not used to train, fine-tune or improve any model, ours or a provider’s. We do not sell data, and we do not share it with anyone for their own purposes.
6.3 What the agent is constrained from doing
The agent has no access to a Customer’s account, database, orders or systems, and cannot retry, refund, cancel or look anything up. It is constrained from stating why an error happened, that a problem is fixed, that data was saved or lost, or that a payment did or did not go through. Conversations are capped in length and expire.
It remains a language model, and no model is perfect. Its output is a support conversation, not a statement of fact by us or by the Customer.
8. Retention
Incident and conversation data is kept for a window set by the Customer’s plan, then deleted. The window is a property of the account, so a Customer can shorten it by changing plan and can delete individual incidents at any time.
| Plan | Incident and conversation data |
|---|---|
| Free | 7 days |
| Pro | 90 days |
| Growth | 180 days |
| Scale | 365 days |
Other categories are kept as follows.
- Account and project data: for as long as the account is open, and deleted within 30 days of account closure.
- Billing records: for as long as required by tax and accounting law in the jurisdiction we are established in.
- Security and audit logs: up to 12 months, then deleted.
- Support correspondence: up to 24 months from the last message.
Where deletion is not immediately possible, for example in an encrypted backup, data is isolated from further processing and deleted when that backup expires.
10. Security
Data is encrypted in transit with TLS 1.3 and at rest with AES-256. Project data is isolated per workspace with a deny-by-default database policy. Dashboard access is passwordless with expiring sessions, and internal access follows least privilege. The full account is on our security page.
We claim no certification, because we hold none. If that changes this section will say so, with the scope and the date.
If a breach is likely to result in a risk to people’s rights and freedoms, we will notify the relevant supervisory authority within 72 hours of becoming aware of it, notify affected Customers without undue delay so they can meet their own obligations to their users, and publish what we found and what we changed.
To report a vulnerability, email hello@cluebase.dev. We will not pursue legal action over good-faith research that respects user privacy and does not degrade the service.
11. International transfers
Our infrastructure and subprocessors operate across several countries, so data is transferred internationally in the ordinary course of running the service. The countries involved for each provider are listed in the subprocessor register.
Where a transfer leaves a jurisdiction that restricts them, we rely on an adequacy decision where one exists, and on standard contractual clauses with the receiving party otherwise. Our own establishment and the governing framework for these transfers are pending incorporation.
12. Your rights
Depending on where you live you have some or all of the following rights over your personal data. They are honoured regardless of whether the law where you live requires it.
- Access: a copy of the data we hold about you.
- Rectification: correction of data that is wrong or incomplete.
- Deletion: erasure of your data, subject to what we must keep by law.
- Portability: your data in a structured, machine-readable format.
- Restriction and objection: to stop or limit processing based on legitimate interests, including direct marketing.
- Withdrawal of consent: at any time, where processing is based on consent, without affecting what was lawful before.
- Complaint: to your local data protection authority.
12.1 How to exercise them
Email hello@cluebase.dev. We respond within 30 days, and will tell you if we need longer and why. We may need to verify your identity first, and where we cannot do what you asked we will say so and explain why.
12.2 If you are an End User
Send your request to the company whose application you were using when the problem happened. They are the controller of that data and can action it directly. If you send it to us instead, we will forward it to them and confirm that we have.
13. Children's data
Cluebase is a developer tool sold to businesses and is not directed at children. We do not knowingly collect data from anyone under 16. A Customer who deploys our SDK in an application used by children is responsible for the consents that requires. If you believe we hold data about a child, email us and we will delete it.
14. Changes to this policy
We update this policy as the product changes and as the law does. The effective date at the top always reflects the current version. For a material change, such as a new category of data or a new subprocessor, we notify Customers by email before it takes effect. Continuing to use the service after that constitutes acceptance.
15. Contact
Questions about this policy, a request about your data, or a security report all go to hello@cluebase.dev. A person reads it.
Postal address and the identity of our data protection contact are pending incorporation.