Create Your First Dashboard and Alert

A dashboard should preserve a reviewed answer. An alert should identify a condition that has an owner and a useful response. Do not promote an unverified query simply because its chart looks plausible.

This walkthrough starts from the request-volume and error-rate SQL in Write Your First Telemetry SQL Query.

Create one decision-oriented widget

Run the query in Telemetry, choose a chart that matches the result, and select Add to Dashboard.

For an API error-rate result:

• Use a line chart when time is the primary dimension.
• Use a bar chart when comparing a small set of route templates.
• Use a table when exact values, volume thresholds, and several measures must remain visible.

Name the widget after the decision, not the implementation. “API server error rate by route” is clearer than “Query 7.”

Keep the denominator visible. A route with one error in one request should not silently outrank a route with 500 errors in 10,000 requests. Include both request volume and error percentage or enforce a minimum-volume condition in SQL.

Keep the first dashboard small

A useful first reliability dashboard might contain:

1. Request volume over time.
2. Server error percentage over time.
3. p95 latency by route.
4. Top error categories or fingerprints.
5. A table of affected accounts only when that access is approved.

Each widget should link back to inspectable rows or saved SQL. Avoid repeating the same metric in several chart styles.

See Creating Dashboards for layout and ownership guidance.

Create a bounded alert

Open a validated chart or query result and select Create Alert. Define:

• The aggregation and measure.
• The last number of data points to evaluate.
• The comparison and threshold.
• The evaluation interval.
• Whether to ignore an incomplete newest bucket.
• The recipient who owns the response.

For a synthetic development table, start with a non-paging email alert. A production example might be:

p95 of the last 5 completed data points is greater than 850 ms

or:

server_error_pct is greater than 5% and requests is at least 100

The exact threshold depends on the service objective, traffic pattern, and response policy. A copied number is not a substitute for a baseline.

Test both sides of the condition

Send controlled synthetic events that should:

1. Leave the alert below threshold.
2. Move the result above threshold.
3. Produce a notification to the expected recipient.
4. Return below threshold after recovery.

Record the query, threshold, recipient, and response link. Then remove or clearly isolate the synthetic rows from production reporting.

Define the response

Every alert needs a short action:

• Open the relevant dashboard.
• Inspect affected routes, releases, and accounts.
• Correlate with a request or workflow identifier.
• Decide whether to mitigate, roll back, or continue observing.
• Record recovery time and customer impact separately.

For alert behavior and troubleshooting, read Alerts and Alert Delivery and Troubleshooting. Before deploying the instrumentation broadly, complete the Production Instrumentation Checklist.