The parameters every query takes, the vocabulary the library assumes, and a worked example of the one label you will see on every dollar figure — est · at list.
Authored from a scan of the query bodies. Most queries take a single time window; a handful hardcode it. There is no server-side default — you supply the window when you run the query.
| Parameter | Kind | Try | What it controls | Scope |
|---|---|---|---|---|
| :period_days | Bind parameter (integer, days) | 30 | The length of the trailing analysis window. Queries filter usage_date ≥ current_date() − :period_days and exclude today. There is no built-in default — you supply it at run time; 30 is the usual starting point, 7 for a fast look, 90 for a billing-cycle view. | The most common parameter — 40+ queries across every domain. |
| :lookback_days | Bind parameter (integer, days) | 7 | Same idea as :period_days, but named separately on the node-level utilization queries where the window is a shorter, higher-resolution slice. | The two node-utilization queries (compute_idle_node_ratio, node_timeline_utilization). |
| fixed 30-day window | Hardcoded literal (not a parameter) | edit the SQL | About thirty queries — most of the governance access_* set plus several jobs / performance / optimization queries — hardcode current_date() − 30 rather than taking a bind parameter. To change their window you edit the literal in the SQL. | ~30 queries (most access_*, several lakeflow_* / query_* / po_*). |
| LIMIT 1000 | Result cap (hardcoded literal) | raise if needed | A row cap, not a filter — the heaviest-statements query returns the top 1000 statements ranked by execution time. Raise it only if the top 1000 isn't enough surface area to triage. | query_costly_statements only. |
usage_quantity is in DBUs (or bytes / hours / tokens for non-compute SKUs) — it is a quantity, never dollars. You get dollars by multiplying DBUs by a price rate.ENTERPRISE_ALL_PURPOSE_COMPUTE or PREMIUM_JOBS_SERVERLESS_COMPUTE. The same work on a different SKU can cost materially more; the SKU string often encodes the tier (e.g. a (PHOTON) suffix).ORIGINAL is the first-billed amount; RETRACTION claws it back (a sign-flipped negative); RESTATEMENT re-bills the corrected amount. Summing all three nets the correction out exactly once — filtering to ORIGINAL overstates spend.system.billing.list_prices). Account price is your negotiated rate (system.billing.account_prices) — which is not present in every environment. When it's absent, these queries fall back to the list/default rate and label the figure unverified.GROUP BY grain — e.g. a single (usage_date × cloud × SKU × product) combination. “An untagged slice” or “an unpriced slice” means one such group, not the whole account.? and emails with <email>, so you see the query shape and identifiers without any literal data values. It lets you group and rank statements by structure while keeping the output safe to share.usage_unit = 'DBU') attributed to a resource over the window, netted across all record types (ORIGINAL + RETRACTION + RESTATEMENT) so corrections are already applied. This is the trustworthy quantity to dollarize.net_dbus × list-rate. It is pre-discount, DBU-only (excludes cloud infra / egress), and directional — never your actual negotiated invoice. See the worked example below.est · at listTake one warehouse that metered 12,500 DBUs over the window. Here is exactly what “est · at list” does — and what it deliberately leaves out.
| net_dbus | 12,500 DBUs (already netted across record types) |
| × list rate | × $0.55 / DBU (illustrative list rate from system.billing.list_prices) |
| = est · at list | $6,875 — the pre-discount, DBU-only estimate the queries report |
| your actual invoice | 12,500 × $0.44 negotiated = $5,500 (≈ 20% discount — not in any system table here) |
| also excluded | cloud infra + egress the SKU triggered — billed by your cloud provider, not Databricks |
$6,875 est · at list is a ceiling for comparison and ranking, not the number on your bill. Use it to size and prioritise findings; never quote it to finance as billed spend. All figures here are illustrative, not real account data.Every field this library renders — query metadata, bands, params, requirements and the next graph — is published as a single machine-readable file. It’s a point-in-time snapshot of the source audit repo, re-copied whenever the library is re-synced.
Download databricks-audit-manifest.json
Back to the first-audit runbook, an investigation trail, or the full query library.