1. Event contract
One row in service_heartbeats, with the types used by the query made explicit.
- timestamp_utc
- Timestamp
- service_name
- Utf8
- environment
- Utf8
- status
- Utf8
How it works
A reviewable workflow from signal to decision
1
Choose a signal with an owner
A threshold is useful only when someone understands what it means and can act. Begin with a user, revenue, or reliability outcome.
2
Set volume and time safeguards
Avoid ratios on tiny denominators, allow for normal scheduling jitter, and ignore incomplete time buckets where appropriate.
3
Test the response path
Trigger the condition with synthetic data, confirm delivery, and include enough context for the recipient to open the right query or dashboard.
Creating an alert from an Explore result
The actual Explore actions that promote a reviewed result into a dashboard or threshold alert.
Boundaries
What this does not replace
- Threshold alerts are not anomaly detection and should use a reviewed baseline, sufficient volume, and complete time buckets.
- Email delivery is not a substitute for a complete incident-management and escalation process.
- Telemetry cannot infer whether a signal is actionable; every alert still needs an owner and a documented response.
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 expected telemetry sources have stopped sending heartbeats?
SELECT
service_name,
environment,
MAX(timestamp_utc) AS last_seen_at,
COUNT(*) AS heartbeats_in_window
FROM service_heartbeats
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY service_name, environment
HAVING MAX(timestamp_utc) < now() - INTERVAL '10 minutes'
ORDER BY last_seen_at ASC;3. Synthetic result
The oldest last_seen_at value should be investigated first.
| service_name | environment | last_seen_at |
|---|---|---|
| billing_sync | production | 2026-07-27 15:04:00Z |
| email_worker | production | 2026-07-27 15:11:00Z |
Capabilities
What is included
Count, sum, average, min, max, and percentile conditions
Greater-than and less-than comparisons
Configurable evaluation interval and recent-point window
Optional exclusion of the newest incomplete bucket
Multiple email recipients and alert history
See the analysis
SQL recipes that use this capability
Detect Missing Service Heartbeats
Find services, workers, or scheduled tasks that stopped reporting before a failure event appeared.
Open recipeFind Stalled Background Jobs With SQL
Join job start and finish events to identify work that exceeded its expected completion window.
Open recipeCalculate API Error Rate by Route
Use SQL to rank API routes by 5xx error rate while protecting the result from low-volume noise.
Open recipeCustomer evidence
How teams use this workflow
Related capabilities
Continue the event-to-decision workflow
AI 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 capabilityStructured event ingestion
Turn application behavior into queryable event tables
Explore capabilityStart with one production workflow
Use a focused prompt, send synthetic events, and verify the first useful query before expanding coverage.