Data Processing

This is a controller-to-controller data sharing statement, not an Art. 28 processor agreement — §1 explains why that distinction is the right one for this service. Every technical claim was checked against the running code (src/) and the schema (schema.sql). If your process requires a counter-signed agreement, write to hello@batchwatch.dev and we will handle it as a contract rather than as a web page.

Companion to PRIVACY.md.

1. Read this first: we are usually not your processor

The front page links to a "data processing agreement", and customers' procurement teams will ask for one. But the honest analysis is that for almost everything batchwatch does, we are a controller in our own right, not a processor acting on your instructions.

The reasoning:

• You do not instruct us to process data on your behalf. You send us measurements and we use them for our own purposes: computing and publishing an aggregate, and selling access to it. TERMS.md §7 takes an explicit — and, since #60, terminable rather than perpetual — aggregate licence to do exactly that.
• We decide what is collected, how long it is kept, how the percentiles are computed, and what is published. Those are controller decisions.
• The hashed-IP records in trial and usage exist for our abuse and quota control, not yours.

So the instrument you actually need from us is a controller-to-controller data sharing statement, which is §§2–8 below. §9 is a fallback Art. 28 processor annex that engages only in the narrow case described there.

Getting this the wrong way round matters. Signing a standard Art. 28 processor DPA would describe a relationship that does not exist, oblige us to "process only on documented instructions" while we plainly do not, and oblige us to "delete or return all personal data at the end of the provision of services" — which directly contradicts the aggregate licence the terms take, even in its terminable form: a withdrawal ends the licence going forward but does not recall an aggregate already published (§9, and TERMS.md §7).

2. What personal data is actually involved

Most of what we hold is not personal data at all: token counts, model names, timestamps, and durations describing machine behaviour.

The parts that are, or may be:

Categories of data subject: developers and operators who create API keys or call the API; visitors to the dashboard (at the Cloudflare edge only). No end users of your applications — nothing about them ever reaches us.

No special categories (Art. 9) and no criminal-offence data are involved, intended or foreseeable.

What is never received: prompts, completions, system prompts, tool definitions, function schemas, provider API keys, end-user identifiers, request IDs. The client library reads timing and token counts off the job and never touches the payload; it is open source, ~90 lines, and that is the point of publishing it.

3. Nature, purpose and duration

Nature: collection, storage, aggregation and publication of queue-time measurements; authentication of API keys; counting of trial calls and quota.

Purpose: operating batchwatch — building a public dataset of LLM batch API queue times, answering queries against it, and commercialising access to the aggregate.

Duration: for as long as the service operates. No automatic deletion is implemented in the code today — verified: there is no TTL, no scheduled purge, and no DELETE statement anywhere in src/. Rolling query windows (30 days, 7 days, 1 hour) mean older rows stop influencing answers, but they are retained. Setting and implementing retention periods for trial and usage is an open item, recorded in PRIVACY.md §6.

4. Security measures actually in place

Stated as what exists, not as what a template would claim.

In place:

• API tokens are stored as SHA-256 hashes, never in clear text. We cannot recover a token — not for an attacker, and not for the owner.
• Tokens carry 32 bytes of entropy from crypto.getRandomValues.
• IP addresses are never written to the database. The trial and key-creation counters store SHA-256(secret_salt + "|" + ip). Only the two-letter country code from Cloudflare's CF-IPCountry header is stored on a measurement row.
• The salt is a Cloudflare secret, not in the repository and not in wrangler.toml. If it is missing the trial is disabled entirely rather than falling back to unsalted hashes — a deliberate fail-closed design.
• The client IP is read only from CF-Connecting-IP, written by Cloudflare's edge and not forgeable by the caller. X-Forwarded-For is deliberately ignored.
• No content ingestion by design. The narrowest possible data model is the primary technical measure: what is not collected cannot leak.
• Free-text is bounded: key labels have control characters stripped and are trimmed to 60 characters; model names are capped at 100.
• TLS in transit and encryption at rest are provided by Cloudflare per their own documentation.
• Responses are no-store, and there is no third-party script, analytics, tag manager or advertising on the API (/v1/…). The public marketing pages carry consent-gated Google Analytics 4 — loaded only after a visitor actively allows it, never before, and never on the measurement routes. See §5 above and PRIVACY.md §9a.
• The application logs one line per prober run and nothing else. No user data is logged by our code.
• Access to production is a single operator with Cloudflare account credentials; there is no shared admin panel and no additional staff.

Not in place — state these honestly to any customer who asks:

• No SOC 2, ISO 27001 or equivalent certification.
• No independent penetration test.
• No formal backup or restore procedure beyond whatever Cloudflare D1 provides by default.
• No audit log of administrative database operations.
• No automated abuse detection.
• No 24/7 on-call, no support commitment on free tiers.
• Single operator, so no separation of duties.
• The abuse defences have published, known limits — see ACCEPTABLE-USE.md §4.

5. Sub-processors

Cloudflare is the only sub-processor in the request path of the measurement service. No customer measurement data reaches anyone else: the API (/v1/…) loads and reports nothing to any third party.

Google Analytics is a sub-processor for website visitors, not for API callers, and only on consent. Nothing is loaded before a visitor clicks Allow; declining loads nothing, ever. See PRIVACY.md §9a.

Stripe is a sub-processor only for people who pay. It is engaged when a customer buys a subscription: checkout is hosted by Stripe, so card data goes straight to Stripe and never touches our systems. Anyone who has not paid is not in Stripe at all — free and contributor keys involve no payment processor whatsoever.

Resend is a sub-processor only for people we have an address for, which is the opt-in verified contributors and the paying customers who left key recovery on. It is not in the request path of the API and receives no measurement data.

Changes to this list. Google Analytics 4 was added on 2026-08-26, Stripe on 2026-08-30 when subscription billing went live, and Resend on 2026-08-31 — recorded when paid key recovery shipped, though the email tier (#145) had already been using it. Every addition is announced under the 30-day notice below, and this section is the authoritative record of what it says today.

The D1 region is not pinned in our configuration. wrangler.toml declares the binding and the database id but no location_hint; the primary region was chosen by Cloudflare at creation time. It still needs to be looked up in the Cloudflare dashboard and recorded here — and until it has been, we do not assert an EU region. If an EU primary is required for a customer, D1 supports a location hint at database creation and moving would mean recreating the database.

Sub-processor change notice period: 30 days, consistent with the 30-day notice already promised in TERMS.md §9.

Our prober calls OpenAI, Anthropic and Google using our own API keys and our own toy jobs (8 tokens in, 5 out). Those providers are not sub-processors of anyone's data: no customer data is sent to them, ever.

6. International transfers

Cloudflare is a US company operating a global network, so personal data may be processed outside the EEA. The basis is Cloudflare's DPA and SCCs, which must be executed. A transfer impact assessment should be done as part of that, and is not done yet.

7. Data subject requests

We handle requests directly, as controller — see PRIVACY.md §7, which sets out exactly what can and cannot be deleted and why.

The one point worth repeating here, because it surprises people: we cannot action a deletion request for measurements submitted without an API key. key_id is NULL on those rows and nothing links them to a person. Art. 11 GDPR applies. If deletability matters to you, submit with a key.

There is no self-service route for export or deletion. Both are manual operations by the operator. Key revocation is the one thing you can do yourself, and it does not by itself delete measurements.

8. Personal data breach

If we become aware of a breach affecting personal data we hold, we will notify affected controllers and, where required, Datatilsynet, without undue delay and in any event within 72 hours of becoming aware.

Realistically, the breach scenarios worth naming are:

1. Compromise of the Cloudflare account. This is the whole system.
2. Disclosure of TRIAL_SALT, which would make the stored IP hashes brute-forceable back to addresses — the exact risk the salt exists to prevent.
3. Database exfiltration. Contents would be measurement metadata, token hashes (not usable to authenticate), key labels, salted IP hashes and the email addresses of contributors who opted in to verify one (§2). No prompts, no completions, no provider credentials, no card data and no passwords — none of those are ever collected.

9. Fallback: Art. 28 processor terms

These terms apply only if, and only to the extent that, we in fact process personal data on your documented instructions — realistically only where you have placed personal data into the free-text model, endpoint or key label fields, which ACCEPTABLE-USE.md §2.9 asks you not to do.

Where they apply, we will:

1. Process that data only on your documented instructions, including as to transfers, unless required otherwise by EU or Member State law.
2. Ensure persons authorised to process it are bound by confidentiality.
3. Apply the measures described in §4.
4. Not engage a sub-processor other than those in §5 without prior notice and an opportunity to object.
5. Assist you, so far as reasonably possible, with data subject requests and with Arts. 32–36 obligations.
6. Notify you without undue delay on becoming aware of a breach affecting that data.
7. At your choice, delete or return that data at the end of the provision of the service, and delete existing copies unless retention is required by law.
8. Make available the information reasonably necessary to demonstrate compliance and allow audits — see the limits below.

Audit: as a single-operator service, we cannot host an on-site audit. We will answer a written security questionnaire and provide the Cloudflare DPA and any Cloudflare compliance reports we are permitted to pass on.

Scope limit that must be preserved in any negotiated version: clause 7 above (delete or return) applies only to data processed on your instructions under this §9. It does not apply to the measurements you contributed. Those are covered by the terminable aggregate licence in TERMS.md §7, which is a controller-to-controller arrangement, not a processing instruction. That licence can be ended going forward by writing to us, and once we act on it we stop using those measurements in new aggregates — but an aggregate already published stands, because a released statistic cannot be recalled. Any customer redline that extends the §9 deletion obligation across that boundary — or that tries to reach back into already-published aggregates — changes the product's foundation and must be escalated, not accepted.

10. Contact

hello@batchwatch.dev · Stenager Consulting ApS, CVR 44456923, Stenagervaenget 45, 7100 Vejle, Denmark.

No Data Protection Officer is appointed, and none is required. The Art. 37 trigger is "regular and systematic monitoring of data subjects on a large scale". We monitor queues, not people: we hold per-person data only as bounded, salted hashes used for abuse control, and we do not profile or track individuals anywhere in the service.