36 synthetic input rows in database_transaction_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
Transaction rollback rate by service
Checkout has both the highest rollback rate and the largest affected-account count.
| service | database_name | transactions | rollbacks | rollback_rate_pct | affected_accounts | average_duration_ms |
|---|---|---|---|---|---|---|
| checkout-api | app_production | 12 | 3 | 25 | 3 | 290 |
| billing-worker | billing_production | 12 | 1 | 8.33 | 1 | 275 |
| catalog-api | catalog_production | 12 | 0 | 0 | 0 | 107.5 |
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.