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. What this page is
When you use Cluebase, some processing of your data happens inside our own systems and some is carried out by companies we rely on: hosting, the database, authentication, the language model behind the recovery agent, notification delivery. Under data protection law these companies are subprocessors, and we are required to disclose them and to give you notice before the list changes.
The register below names each one, what it does for us, the data it touches, and where it processes that data. It is deliberately complete rather than curated: if a company processes customer or end-user data for us, it is on this page, including the ones that only see data in transit.
2. The register
| Subprocessor | Purpose | Data processed | Location |
|---|---|---|---|
| Vercel | Application hosting and edge network | All data in transit, request logs | United States, global edge |
| Vercel AI Gateway | Routing of AI model requests | Error context and conversation messages, in transit | United States |
| DeepSeek | The language model behind the recovery agent | Error context and conversation messages, for the duration of the request | Served through Vercel AI Gateway |
| Supabase | Primary database and storage | Accounts, projects, incidents, conversation transcripts | Configured region |
| Clerk | Authentication and session management for the dashboard | Customer name, email, authentication metadata | United States |
| Slack | Incident notifications, where a customer connects it | Incident summary and end-user details, as configured by the customer | United States |
| Telegram | Incident notifications, where a customer connects it | Incident summary and end-user details, as configured by the customer | Global |
| Svix | Outbound webhook delivery | Incident payloads, in transit | United States |
The language model row is the one most worth reading in full. Every widget conversation, and the error context attached to it, is sent to a third-party model to generate the agent’s replies. What is sent, and what is never sent, is described in privacy policy section 6.
3. How we engage subprocessors
3.1 Before adding one
We add a subprocessor only when the product needs it to function, and we check before engaging: what data the integration actually transmits, whether the provider offers a data processing agreement, where the data lands, and whether less data would do. The register records the outcome of that check, not the provider’s marketing description.
3.2 While engaged
We pass each subprocessor the minimum the integration requires, which is why several rows above say in transit or for the duration of the request: for those providers the exposure is the transmission itself, and nothing is stored on their side by us. Where a subprocessor stores data, the row says what it stores.
4. Changes to the register
Adding a subprocessor, or changing what an existing one processes, is a change to how the service handles data, so you hear about it before it takes effect. We announce material changes in advance under section 14 of the terms, and this page carries the updated list on the day the change takes effect. Where a change requires updating the privacy policy, both documents move together so they never disagree.
If you disagree with a new subprocessor, your remedies are the contract’s ordinary ones: object to us, or terminate under section 12 of the terms.
5. Contact
Questions about a subprocessor, or about this register, go to hello@cluebase.dev.
Related documents