1. Event contract
One row in api_requests, with the types used by the query made explicit.
- timestamp_utc
- Timestamp
- route_template
- Utf8
- status_code
- Int64
- latency_ms
- Float64
How it works
A reviewable workflow from signal to decision
1
Lead with the decision
A dashboard should answer a small set of related questions. Start with the primary health or outcome metric rather than every available chart.
2
Place diagnosis after detection
Put trend and threshold views first, then add breakdowns and recent-event tables that explain a change.
3
Document ownership and response
Use headers and notes to define the metric, expected range, owner, and next step. Context makes the dashboard usable during an incident.
Building a shared Telemetry dashboard
A real product capture showing chart arrangement and collaborative dashboard editing.
Boundaries
What this does not replace
- Dashboards summarize reviewed queries; they do not make an unstable metric definition trustworthy.
- A shared board should stay focused on a small decision set instead of becoming an inventory of every available chart.
- Telemetry dashboards do not replace an incident runbook, ownership model, or durable source-of-truth system for financial reporting.
Inspectable proof path
From event contract to a visible answer
This example uses a declared schema, read-only SQL, and deterministic synthetic results. It demonstrates the workflow without presenting sample data as a customer benchmark.
2. Read-only SQL
Which API routes have the highest meaningful 5xx error rate?
SELECT
route_template,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
HAVING COUNT(*) >= 20
ORDER BY error_rate_pct DESC
LIMIT 10;3. Synthetic result
The checkout route is the clearest reliability risk even though search has more total traffic.
| route_template | requests | errors |
|---|---|---|
| /api/checkout | 25 | 5 |
| /api/search | 25 | 1 |
| /api/profile | 20 | 0 |
Capabilities
What is included
Explore and SQL query widgets
Line, bar, scatter, stacked-area, and table results
Section headings and markdown notes for context
Drag, resize, rename, and share team-scoped dashboards
Dashboard create, update, list, and delete API
See the analysis
SQL recipes that use this capability
Calculate API Error Rate by Route
Use SQL to rank API routes by 5xx error rate while protecting the result from low-volume noise.
Open recipeMeasure Webhook Retry Recovery
Separate permanent webhook failures from deliveries that recovered on a later attempt.
Open recipeBuild a Signup-to-Activation Funnel in SQL
Calculate unique-user conversion through signup, onboarding, integration, and first-value milestones.
Open recipeCustomer evidence
How teams use this workflow
“Telemetry makes it super easy to track, analyze, and visualize what's going on in my business. It's the perfect mix of simple and powerful.”
Namu Kang, Browserflow
Review the documented workflow“Telemetry is my go-to for dumping logs and tracking events. It's straightforward, the SQL workbench is fast, and I don't have to worry about the schema upfront. Running SQL over a REST API lets me fetch data and dump reports straight to Slack. It's the essentials of what Sentry did for me.”
Prem Viswanathan, SwiftCX
Review the documented workflowRelated capabilities
Continue the event-to-decision workflow
Threshold alerts
Notify people when a queryable signal moves outside its expected range
Explore capabilityAI agent monitoring
Monitor AI agent cost, tool use, and outcomes with structured events
Explore capabilityAI-assisted analysis
Turn a plain-language question into SQL you can inspect and improve
Explore capabilityStart with one production workflow
Use a focused prompt, send synthetic events, and verify the first useful query before expanding coverage.