Template

Event Schema & Telemetry Naming Template

A structured, fillable event schema template to define telemetry contracts, naming conventions, ownership, versioning, validation, retention, privacy classification, downstream consumers, and governance steps. Submissions create a consistent, reviewable record teams can use to register events and reduce inconsistent or missing telemetry.

Interactive Tool

Event Schema & Telemetry Naming Template

Use this interactive template to define a tracked event and its telemetry contract. Completing this form produces a consistent, versioned event definition suitable for cataloging, review, and downstream validation. Good telemetry starts with clear names, stable keys, documented properties, and explicit ownership.

Fill required fields, attach example payloads, run validation tests, then submit. The structured output is designed to be saved, reviewed by governance, and linked to a schema registry or event catalog.

A short, stable machine-readable identifier (use snake_case or kebab-case). Treat this as the canonical key used in pipelines; changing it breaks consumers.
A clear name product teams and analysts will recognize. Avoid product-internal abbreviations.
What this event represents, when it should be emitted, and why it exists. Include any domain context analysts need.
Team or contact responsible for the event schema and for communicating changes to consumers.
Semantic version (e.g., 1.0.0) or date-tagged version. Increment when you change the contract in incompatible ways.
Choose the naming pattern used across events and properties for consistency.
List required property names with types and brief descriptions. Example: user_id: string (UUID) — identifier for the user who triggered the event.
List optional properties with types and descriptions and indicate when they may be present.
Provide a concrete JSON example exactly as emitted. This helps implementers and downstream consumers understand the shape and types.
Recommended retention period for raw events. Note regulatory or business requirements if longer retention is needed.
Expected frequency, acceptable latency, retry behavior, and monitoring/alerting expectations for the emitter.
List teams, dashboards, reports, models, or pipelines that consume this event. Include owner contacts where available.
Identify whether the event contains PII, PHI, or other regulated data and reference required controls.
Complete these items before the event is considered registrable and safe for downstream consumption.
Describe steps to add this event to the catalog, including reviewers, approval criteria, and expected SLAs for review.
Link to the canonical schema (e.g., Avro/JSON Schema/Protobuf) or repo where the event contract is stored.
Provide links to real examples in staging or production to illustrate the event in context.
Notes about backwards compatibility, advice for consumers in case of changes, and any migration steps required.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Sign In to Save Create an Account
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.
Discuss Ask the Librarian

Discussion

Comments and conversation will live here.