34 synthetic input rows in database_query_events. Timestamps shift into the current query window when the fixture loads.
Results are capped at 500 rows. The included fixtures are synthetic and intentionally small.
No fixture or query is sent to Telemetry.
Published expected result
Query output and visualization
Query result
Slow-query rate by fingerprint
The invoice update is slow on most executions, while the catalog query remains below the illustrative one-second threshold.
| query_fingerprint | service | database_name | executions | slow_executions | slow_query_rate_pct | average_duration_ms | maximum_duration_ms |
|---|---|---|---|---|---|---|---|
| UPDATE invoices SET status = ? | billing-worker | app_production | 10 | 8 | 80 | 1,250 | 1,700 |
| SELECT checkout WITH line_items | checkout-api | app_production | 12 | 6 | 50 | 1,012.5 | 1,600 |
| SELECT products BY category | catalog-api | catalog_production | 12 | 0 | 0 | 330 | 440 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
What this playground proves—and what it does not
The browser runner proves that the selected read-only query executes against its included rows and produces the displayed result. The browser downloads the versioned DuckDB runtime from jsDelivr only after you run a query; the SQL and fixture are not sent with that request. Telemetry recipes are separately planned with Apache DataFusion, the engine used by Telemetry. DuckDB and DataFusion are distinct SQL engines, so validate any edited syntax with the DataFusion SQL reference before using it in production.