Skip to content
Data quality

telemetry_delivery_observed event schema

An event your app records for a telemetry delivery attempt. Send it to a separate destination or sample a limited number of attempts so logging a delivery does not create another delivery event indefinitely.

Reviewed by the Telemetry product team on . We checked what each event represents, which service sends it, field types, sensitive data, the example, and validation steps. Who reviews this page

Question this event answers

Are application events arriving completely, promptly, and without retry amplification?

Fields
11
Required
10
Send and check an event

Record and query telemetry_delivery_observed

Document what each telemetry_delivery_observed row represents and which service sends it. Send test events to check the fields, then verify that the query answers your question.

  1. 1

    Outcome becomes final

    Shared instrumentation or telemetry delivery library emits only after a delivery succeeds, is rejected, times out, or reaches its retry limit.

  2. 2

    Choose the fields

    10 required fields preserve the declared grain: One sampled or aggregated observation per delivery attempt or delivery window.

  3. 3

    Check the test event

    Check types, UTC time, alternate outcomes, idempotency, and every pseudonymous or review-classified field.

  4. 4

    Query the result

    Are application events arriving completely, promptly, and without retry amplification?

Grain

One sampled or aggregated observation per delivery attempt or delivery window.

Owner

Shared instrumentation or telemetry delivery library

Emit when

After a delivery succeeds, is rejected, times out, or reaches its retry limit.

Field contract

Field types and data to exclude

Keep field names and types stable once production queries depend on them. Document optional fields and add them only when they answer a specific question.

FieldTypeRequiredPrivacyMeaning
timestamp_utctimestampyesnon-sensitiveUTC time when the operation finishes.
event_idstringyesnon-sensitiveStable unique identifier used for deduplication.
releasestringyesnon-sensitiveApplication or service version that emitted the event.
account_idstringyespseudonymousStable internal account identifier, never an email or name.
target_tablestringyesnon-sensitiveAllowlisted destination event table.
delivery_statusstringyesnon-sensitiveAccepted, rejected, timed_out, or transport_failed.
attempt_countnumberyesnon-sensitiveNumber of delivery attempts, up to the retry limit.
batch_sizenumberyesnon-sensitiveNumber of logical events in the delivery.
payload_bytesnumberyesnon-sensitiveSerialized request size in bytes.
duration_msnumberyesnon-sensitiveTotal delivery duration, including retries.
error_typestringnonon-sensitiveControlled transport or rejection category.

Synthetic JSON event

{
  "timestamp_utc": "2026-07-29T10:31:04Z",
  "event_id": "evt_delivery_01",
  "account_id": "acct_8f31",
  "release": "2026.07.3",
  "target_table": "api_request_completed",
  "delivery_status": "accepted",
  "attempt_count": 1,
  "batch_size": 20,
  "payload_bytes": 8420,
  "duration_ms": 146
}

Privacy review

Review identifiers before ingestion

This example uses synthetic identifiers. Pseudonymous values can still be personal data, and review fields can expose business or provider context. Apply your own consent, retention, access, residency, and deletion requirements.

  • account_id: pseudonymous

Validation checklist

Test the schema before building a dashboard

  • Send one known telemetry_delivery_observed fixture after the documented outcome boundary.
  • Verify all 10 required fields arrive with the documented types.
  • Retry the same event identifier and confirm the chosen deduplication behavior.
  • Send a controlled failure or alternate outcome when the workflow supports one.
  • Run the related SQL over a fixed window and reconcile the result to the fixture.

Common mistakes

Record one result per row

  • Emitting telemetry_delivery_observed before shared instrumentation or telemetry delivery library knows the final outcome.
  • Mixing different kinds of results in one table, which makes counts and rates ambiguous.
  • Replacing controlled categories with raw URLs, payloads, prompts, or error text.
  • Changing a field type in place after saved queries and dashboards depend on it.
  • Adding identifiers without a documented investigation, access, and retention need.

Use the contract

Query the event and set up monitoring

Related contracts

Send a test event before production traffic

Create a free API key, send the synthetic event, and inspect the inferred table before connecting a live workflow.

Test this schema