Data Processing Agreement

This Data Processing Agreement ("DPA") sets out how telemetry.dev handles the personal data inside the telemetry you send us. It forms part of the Terms and takes effect when you accept them, so there is nothing to sign. If your organization needs a countersigned copy, write to [email protected].

Where this DPA and the Terms disagree about personal data, this DPA wins.

1. Who is who

You are the controller of the personal data in your telemetry. We are the processor, and we act only on your instructions. Where you are yourself a processor for someone else, we are the sub-processor and the same terms carry down the chain.

"Customer Data" means the traces, spans, logs and metrics your applications send to our ingest endpoint, together with the account and project records that describe them.

2. What we process, and why

Purpose. We receive telemetry from your AI applications, normalize it, redact it, store it, and show it back to you as traces, charts and searches. We also count ingestion units to bill you. Nothing else.

Duration. We hold each telemetry record for your project's retention window: 7, 14, 30 or 90 days. Account records last as long as your account does.

Types of personal data. Two kinds, from two different sources.

Account data, which you give us directly: name, email address, profile image, the account identifier from GitHub or Google if you sign in that way, and the IP address and browser user-agent attached to each session.

Telemetry data, which your applications send us: span and trace names, model and provider names, token counts, cost, latency and error details, plus — unless you turn capture off — the prompts, completions, tool call arguments and tool results your application produced. Spans also carry any user_id, session_id and conversation_id you set, and whatever else you put in span attributes and metadata.

Categories of data subjects. The people in your organization who hold telemetry.dev accounts, and the end users of your applications whose prompts, identifiers or content appear in the telemetry you send.

We cannot know in advance what your prompts hold. What lands in Customer Data is your decision, which is why the controls below exist.

3. The controls you hold

Three settings limit what we ever store. All three run at ingest, before anything reaches disk.

Capture switches. Every project has a per-environment switch for input capture and output capture. Turn capture off for an environment and we drop prompt, message, completion and tool-payload fields from every span in that environment before storage. You keep the timings, token counts, costs and error rates.

Custom redaction patterns. Every project takes a list of regular expressions. We apply them to each string we store and replace what matches. Patterns compile through RE2, so a slow pattern cannot stall your ingestion.

Retention. Every project holds data for 7, 14, 30 or 90 days. A background job prunes rows past the window, and the storage engine enforces the outer limit as a backstop. Shortening the window also clears data already stored.

Whatever those settings say, we always redact:

• Credentials — private key blocks, Bearer tokens, JWTs, OpenAI-style sk- keys, AWS access key IDs, Google API keys, GitHub tokens, Slack tokens, our own td_live_ keys, passwords embedded in URLs, and api_key, password, secret or token assignments in text and JSON.
• Personal identifiers — email addresses, US Social Security numbers, phone numbers, and card numbers that pass a Luhn check.
• Anything named like a secret — an attribute called authorization, cookie, password, secret, token, credential or api_key is dropped, not stored.

One limit worth stating plainly: redaction is pattern matching, and pattern matching is never complete. It will not catch a name written into a sentence or a customer record buried in a tool result. You stay responsible for what your applications send us and for having a lawful basis to send it.

The service's source code is private. For questions about these controls, contact [email protected].

4. What we owe you

We follow your instructions. Your documented instructions are the Terms, this DPA, and the settings you pick in the product. We process Customer Data for no other purpose. If we ever believe an instruction breaks data protection law, we will say so.

We do not train on your data. We send Customer Data to no model provider, and we use it to train and improve no model. Reading your telemetry is something the product does for you, not something we do for ourselves.

We do not sell your data. Under the CCPA we are a service provider, not a business and not a third party. We have never sold or shared personal information and do not intend to.

Our people are bound to confidence. Access reaches only the staff who need it to run the service, and their duty of confidence outlives their time here.

We help you answer data subjects. When someone asks you for access, correction, export or deletion, the product is usually the fastest route: telemetry is queryable by the user_id you set, retention can be shortened, and deleting a project deletes its telemetry. Where the product falls short we will help directly. If a request reaches us instead of you, we pass it on rather than answer it ourselves.

We help you meet Articles 32 to 36. We will support your security assessments, your data protection impact assessments, and any prior consultation with a regulator, so far as the information is ours to give.

We tell you about breaches. If we find a personal data breach affecting Customer Data, we will tell you without undue delay and include what we know: what happened, which data and roughly how many records, the likely consequences, and what we are doing about it. We will keep you posted as we learn more.

5. How we keep it safe

• Traffic to telemetry.dev and ingest.telemetry.dev runs over TLS.
• Ingest API keys are stored as SHA-256 hashes. We keep a 16-character prefix so you can tell keys apart; the key itself appears once, at creation, and we cannot recover it. Revoking a key stops the next request that uses it.
• Passwords are stored hashed, never as plain text.
• Every telemetry query is scoped to a project and checked against your organization membership and role, so one organization's queries cannot reach another's rows.
• The analytics database has no public address. It answers only over the private network, and the ingest, dashboard and migration paths each hold separate credentials with different rights.
• Ingest and the dashboard run as separate services, so trouble in one does not drag down the other.

We hold no SOC 2 report and no ISO 27001 certificate today. We would rather tell you that than let a page of security language imply otherwise.

6. Sub-processors

You give us general authorization to use the sub-processors named on our sub-processor page. Each is bound by terms no weaker than these, and we remain liable to you for what they do.

We update that page before a new sub-processor starts handling Customer Data. Write to [email protected] if you would rather hear about it by email and we will add you to the notice list. Object on reasonable data protection grounds within 30 days and we will look for an alternative; if none exists, you may stop using the affected part of the service and cancel the rest of the term without penalty.

7. Where your data lives

Our services and databases run in the United States, in Northern Virginia. Personal data you send from the EEA, the United Kingdom or Switzerland is transferred to the United States.

For those transfers we rely on the European Commission's Standard Contractual Clauses, brought into this DPA by reference: Module Two where you are a controller, Module Three where you are a processor. The UK International Data Transfer Addendum covers United Kingdom data. For Swiss data the Clauses apply with the Federal Data Protection and Information Commissioner as supervisory authority. Section 2 supplies the details the Clauses ask for, and section 5 is the description of technical and organizational measures.

8. Audits

We will give you what you need to show that we meet Article 28, and we answer reasonable security questionnaires. For questions about the processing controls, contact [email protected].

Where that is not enough, you or an auditor you appoint may inspect our processing once a year, on reasonable notice, at your cost, under confidence, and at a time that does not disturb the service. A regulator may inspect on whatever terms the law gives it.

9. Getting your data back, and getting rid of it

While your account is open you can read everything we hold through the dashboard and the HTTP API.

Telemetry then clears itself when its retention window closes. Deleting a project deletes that project's telemetry; deleting an organization deletes the telemetry of every project inside it. Both take effect at once and neither can be undone.

When your account closes we delete Customer Data from live systems. Copies sitting in infrastructure backups go as those backups age out. We keep only what the law requires us to keep, such as billing records, and nothing beyond that.

10. Changes

We will update this DPA as the service changes, and the date at the top of the page shows when we last did. If a change cuts your rights in a material way, we will email account owners before it takes effect.

Questions about any of this go to [email protected].