Telemetry

Beta

Telemetry is in beta: included with paid plans at no extra cost during the beta, with limits subject to change. Limits & Errors lists what each plan includes.

Monitors show that something broke. Telemetry shows why. Application logs, traces, metrics and events land in the same console as monitors and incidents.

How telemetry works

1. Create a Stream. An Events Stream takes website analytics, product events and simple logs. An OpenTelemetry Stream takes logs, traces and metrics. Each Stream has a separate retention.
2. Issue an ingest key. Each key writes to one Stream and nothing else, so the key alone decides where data goes.
3. Send data. Point an OpenTelemetry SDK at our ingest endpoint, or POST JSON from anything that can make an HTTP request.

Data shows up under Telemetry in the Console, usually within a couple of seconds. Explore searches every Stream's logs, traces and events at once (stream:checkout narrows the search to one), and a live indicator shows when data is arriving.

Two ways to send

	Best for
OpenTelemetry	Apps and services. Automatic traces, metrics and logs from the standard SDK in every major language, to an OpenTelemetry Stream.
HTTP API	Events and simple logs from scripts, cron jobs, browsers and webhooks, to an Events Stream.

Unsure? Start with OpenTelemetry. As the industry standard, OpenTelemetry instrumentation carries no lock-in.

Signals

Signal	Question answered	Example	Stream
Events	What happened?	pageviews, signups, deploys, with a built-in Analytics dashboard	Events
Logs	What did the code say?	payment failed for order o-9	Events or OpenTelemetry (JSON or OTLP)
Traces	Where did the time go?	one checkout request, span by span, across services	OpenTelemetry
Metrics	Which way is the trend?	requests per second, p99 latency, queue depth	OpenTelemetry

Reliable delivery

By the time our ingest answers 202 Accepted (or 200 for OpenTelemetry), the data is already replicated across regions. Storage writes happen in the background, and when storage is slow, data waits in that buffer instead of being dropped.

Requests that can't be taken get a 429 or 503 with a Retry-After header. OpenTelemetry SDKs retry those automatically. Details in Limits & Errors.

Next steps

• Quick Start: first event in two minutes
• OpenTelemetry: instrument an app
• Streams & Keys: types, retention, keys, usage and ingest health
• Explore & Search: search every Stream at once, and the search syntax
• Monitors: alerts on logs, traces, events and metrics, with heartbeats and composites
• Heartbeat Monitors: alerts when a cron job, backup or worker stops checking in
• Derived Metrics: turn logs and spans into metrics as they arrive
• Log Patterns: what services are logging, grouped
• Limits & Errors: plan budgets, rate limits and every response