Telemetry
Security and data handling

Keep telemetry useful without treating every payload as safe

A practical overview of the controls documented in the product and the instrumentation boundaries teams should decide before sending production events.

Reviewed by the Telemetry product team on . Public product controls, documentation evidence, and claims boundary. Review standards and ownership

Need a security review?

Contact Telemetry for current infrastructure, vendor, contractual, or questionnaire details that are not asserted on this public overview.

Contact security

Scoped API keys

Telemetry documents read, write, and read-and-write scopes. Use separate keys for ingestion, querying, and automation when responsibilities differ.

Queryable event storage

Incoming JSON is checked for schema compatibility, buffered for fresh queries, and written as compact Parquet history used by the DataFusion query layer.

Retention and deletion controls

Table APIs expose configurable retention, row deletion, and table deletion. Treat deletion as irreversible and restrict write-capable credentials.

Payment-data boundary

Telemetry's privacy policy states that payment card details are provided directly to the payment processor and are not stored or collected by Telemetry.

Evidence map

Trace each public claim to its source

Use these references during an implementation review. For hosting regions, infrastructure vendors, subprocessors, certifications, penetration testing, or contractual commitments, request a current verified answer instead of inferring one from product documentation.

Ingestion contract and schema checks

Request shape, authentication, schema compatibility, and response behavior.

Storage and query architecture

The documented buffering, Parquet history, and DataFusion query path.

Credential scopes

Read, write, and read-and-write API-key responsibilities.

Retention and deletion

Table retention settings plus row and table deletion operations.

Sensitive-data minimization

Practical redaction guidance for secrets, payloads, prompts, and personal data.

Public assurance status

What is documented—and what still needs a verified answer

Reviewed July 30, 2026 against the public pages in this site. “Not publicly asserted” means this page does not make the claim; it does not prove that a control is absent. Request current evidence before making a procurement, compliance, or risk decision.

API authentication and scopes

Publicly documented

Read, write, and read-and-write key scopes are documented. This is an application control, not a claim about enterprise identity features.

Retention and deletion

Publicly documented

Table retention, row deletion, and whole-table deletion behavior are documented, including irreversible operations.

Hosting and data location

Policy statement; reconfirm

The privacy policy names AWS and United States processing. It does not provide a current region list or customer-selectable residency commitment.

Payment processing

Policy statement

The privacy policy names Stripe and states that payment-card details go directly to the processor rather than being stored by Telemetry.

Encryption, key management, and tenant isolation

Not publicly asserted

The public pages reviewed do not specify encryption-at-rest design, key ownership or rotation, or the technical tenant-isolation model.

Backups, recovery, and availability commitments

Not publicly asserted

The public pages reviewed do not specify backup frequency, restore testing, recovery objectives, uptime commitments, or a disaster-recovery architecture.

Independent assurance and testing

Not publicly asserted

No public SOC 2, ISO 27001, penetration-test, vulnerability-disclosure, or audit-report claim is made on this page.

Subprocessors and contractual privacy terms

Request current documents

The privacy policy names some service providers, but it is not presented as a current subprocessor register, DPA, SCC package, or complete vendor inventory.

Enterprise access controls

Not publicly asserted

No public claim is made here for SAML SSO, SCIM, configurable RBAC, audit-log immutability, IP allowlists, or customer-managed keys.

Instrumentation boundary

Data to keep out by default

  • Passwords, API keys, auth headers, cookies, and session tokens
  • Private keys, wallet mnemonics, signatures, and credentials
  • Raw prompts, completions, webhook bodies, and job payloads unless specifically reviewed
  • Payment-card data and unnecessary personal or customer content

Safer event design

Prefer categories and identifiers

  • Record error_type and failed_step instead of a raw sensitive payload
  • Use route templates rather than URLs containing identifiers
  • Store accepted, saved, retried, or discarded outcomes without raw AI content
  • Keep environments, services, owners, and stable event names consistent

Security claim publication gate

Evidence required before an unasserted control changes status

A questionnaire answer, roadmap item, or private implementation detail does not automatically become a public assurance. Each new claim must pass all of these checks and be approved in its exact published scope.

  • Control owner and approval of the exact public language
  • Current primary evidence with a review date and expiration or revalidation date
  • In-scope services, environments, data, tenants, regions, and exceptions
  • Implementation and operating evidence rather than a roadmap statement
  • Contractual or policy boundary when the public summary is not a commitment

The record is an intake and review tool. Completing it does not make a claim public or convert private evidence into a contractual commitment.

Public documentation and policy

This page is a product overview, not a contractual security addendum. The privacy policy and terms govern their respective subjects; contact Telemetry for current answers to requirements not covered publicly.