Saved queries, history, favorites, and collaboration

Save a query so teammates can run it again. Telemetry groups saved queries in workspaces and keeps their edit history. Each person can favorite the queries they use most.

Saving SQL does not make the metric correct. Review the event grain, filters, denominator, units, and time boundaries before other people or automated workflows depend on it.

Choose a workspace

Use workspaces to group related analysis by service, product area, operating workflow, or team. Workspaces can be nested, which lets a broad area contain more focused collections without forcing every query into one flat list.

Keep the structure shallow enough to scan. A practical arrangement might be:

reliability
  api
  background-jobs
product
  activation
  retention
ai
  model-cost
  agent-quality

Team membership controls who sees workspaces and saved queries. A workspace name such as "personal" describes organization or ownership; it does not make that workspace private. Every team member can reach the team's workspace analysis, so use a separate team when a query contains identifiers or operational detail intended for a narrower audience.

Save and name a query

Start in a draft, run the query against a representative time range, and inspect the result. When it is ready to keep:

1. Save it in the workspace that owns the decision.
2. Rename it with the outcome, scope, and unit where useful.
3. Keep volume beside rates and percentiles.
4. Add the result to a dashboard only after the saved version is reviewed.

Prefer Production API error rate by route over query 14 or incident query. A name should help someone find and interpret the query without opening every result.

Understand query history

Saving changes creates query history. Use the history entries to review how SQL evolved and to recover the previous logic when an edit changes the result unexpectedly.

Before materially changing a shared query:

• note the old and new metric definitions;
• compare both versions over the same fixed window;
• identify dashboards, alerts, or reports that use the query;
• preserve the previous version until consumers have reviewed the change;
• update explanatory dashboard text when the meaning changes.

History is not a substitute for a broader audit trail or code review process when a query powers regulated reporting, access decisions, or exact financial reconciliation.

Use favorites as a personal shortcut

Favorites are per-person navigation aids. Favoriting a query does not change its workspace, permissions, SQL, or status for other team members. Use favorites for active incident views, weekly reviews, or recurring product questions without duplicating the shared query.

Promote stable results

A saved query can become:

• a dashboard chart or result table;
• an alert with an explicit threshold and owner;
• a repeatable export;
• a starting point for a deeper investigation.

Keep the metric's definition in the saved SQL. Add an owner and response instructions to its dashboard or alert so the next person knows what to do.

Collaboration checklist

Before sharing a saved query broadly, confirm:

1. Every team member is an intended audience for the workspace and query.
2. The title describes the result and units.
3. The SQL uses documented fields and counting rules.
4. A representative fixture or known interval has been checked.
5. Sensitive raw identifiers are omitted from broad dashboards.
6. Material changes are compared with the preceding history entry.
7. Every alert has an owner, evaluation window, and response action.

Continue with Creating Dashboards, Alerts, or Teams, Workspaces, and Members.