One file per Metabase question. Each file is a single SQL statement — open it, copy all, paste into + New → SQL query → plant, run, and Save with the suggested question name in the file's header comment.
| File | Metabase question | Chart |
|---|---|---|
| 01_oee_by_machine.sql | OEE by machine | bar (x=machine_id, y=oee) |
| 02_failure_breakdown.sql | Failure breakdown by type | bar (x=failure_type, y=events) |
| 03_hourly_downtime.sql | Hourly downtime % | line (x=hour, y=pct_downtime) |
| 04_tool_wear_trend.sql | Tool wear trend | line (x=ts, y=tool_wear_min) |
| 05_data_quality_checks.sql | Data quality checks | table (all values should be 0) |
| 06_live_sensor_monitor.sql | Live sensor monitor | line (x=ts, y=tool_wear_min, one line per machine) |
The 2000-row cap (read before debugging a "frozen" live chart): Metabase returns at most 2000 rows per query by default. For aggregate charts that's irrelevant. But a live chart over raw rows must return only RECENT rows — otherwise an unbounded
ORDER BY tshands back the first 2000, which are the OLDEST (the backfill), and the chart looks stuck on old data. Two ways to get the recent tail: a time window (WHERE ts > now() - interval '5 minutes') or a row count (ORDER BY ts DESC LIMIT 1000, wrapped in a subquery re-sorted ascending so the line draws left-to-right). Both re-run on every auto-refresh, so the view tracks "now". Worked examples:04_tool_wear_trend.sql(single machine, LIMIT form) and06_live_sensor_monitor.sql(all machines).
These files are reference/documentation only — nothing in the stack executes
them. Metabase stores each question's SQL in its own application database once
you paste it. The original single-file version (../01_kpi_queries.sql) is kept
as an all-in-one overview.