Event contract
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | Sample or transition time in UTC. |
| cluster | Utf8 | Controlled cluster name. |
| namespace | Utf8 | Kubernetes namespace. |
| workload | Utf8 | Deployment, StatefulSet, or Job owner name. |
| pod | Utf8 | Pod identifier for restricted drill-downs. |
| event_name | Utf8 | Controlled sampled or container_restarted event. |
| restart_count | Int64 | Observed cumulative container restart count. |
| ready | Boolean | Whether the pod was ready at the sample. |
| environment | Utf8 | Deployment environment. |
Copy the query
SELECT
cluster,
namespace,
workload,
COUNT(*) AS observations,
SUM(CASE WHEN event_name = 'container_restarted' THEN 1 ELSE 0 END) AS restart_events,
MAX(restart_count) AS max_restart_count,
SUM(CASE WHEN ready THEN 0 ELSE 1 END) AS not_ready_observations,
100.0 * SUM(CASE WHEN ready THEN 0 ELSE 1 END)
/ NULLIF(COUNT(*), 0) AS not_ready_rate_pct
FROM kubernetes_workload_events
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY cluster, namespace, workload
ORDER BY restart_events DESC, not_ready_rate_pct DESC, workload;This read-only query is planned and executed against an empty typed table with Apache DataFusion 45.2.0. The deterministic sample output is synthetic and reviewed separately; validate field types, thresholds, and business definitions against your own data. Read the testing methodology.
Query result
Restart and readiness signals by workload
Checkout has more restart transitions and not-ready observations than the billing worker.
| cluster | namespace | workload | observations | restart_events | max_restart_count | not_ready_observations | not_ready_rate_pct |
|---|---|---|---|---|---|---|---|
| production-us | application | checkout-api | 5 | 2 | 4 | 2 | 40 |
| production-us | application | billing-worker | 4 | 1 | 2 | 1 | 25 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
Reproduce the example
Download the public fixture
The JSON bundle includes the typed event contract, reproducible input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.
How the SQL works
- 1Workload ownership is more stable than pod names and maps the result to a deployable unit.
- 2Restart transitions are counted separately from the cumulative counter to avoid summing gauges.
- 3Readiness observations keep the operational symptom beside a potential serving impact.
Edge cases to decide
- A rollout naturally replaces pods; distinguish planned replacement from repeated container restart.
- Counters can reset when pods are recreated, so use transition events for rates.
- Join deployment and application-release context before attributing a restart to a code change.
Recommended dashboard
- Stacked bars: restart_events and not_ready_observations by workload
- Trend: restart transitions by cluster and namespace
- Table: latest affected pods with release and controlled reason
Alert guidance
Alert on repeated restart transitions plus sustained readiness loss, not on an isolated rollout replacement.
Read alert setupPut the recipe to work
Related instrumentation and guides
Continue the analysis
Find Host and Container Resource Saturation
Rank infrastructure sources by sustained CPU, memory, and disk utilization while preserving sample volume.
Open recipeFind Cache Misses and Stampede Risk
Compare hit rate, backend cost, and concurrent misses by bounded cache-key pattern.
Open recipeCalculate Incident Detection and Recovery Time
Calculate time to detect and time to recover from structured incident lifecycle events.
Open recipeRun it on real events
Create a table, adapt the fields, and save the result
Start free, send structured events, and use the query result as a chart, shared dashboard widget, or alert input.