Shared SQL warehouses whose bill cannot be split across the teams using them

One endpoint, many consumers, one line item

A SQL warehouse is the piece of Databricks compute most likely to be shared: the finance dashboard, the analytics team’s ad-hoc queries, and a partner’s BI tool can all hit the same endpoint, and the bill arrives as one undifferentiated warehouse cost. That sharing is what distinguishes this rule from its cluster and job siblings. A cluster’s uptime usually has one owner and a job’s runs belong to one pipeline, but a warehouse’s spend is collective by construction, which makes an ownership label the minimum viable accounting.

Scope and trigger

Running warehouses are checked for the 3 canonical keys (team, environment, and cost-center), and the finding fires when any one is missing, listing exactly which. Stopped and errored warehouses are skipped: they bill nothing, so the tag gap is not actionable spend until the warehouse starts again, at which point the finding returns. A tag payload that fails to parse produces no finding rather than a guess.

Read warehouse tags over the API

databricks api get /api/2.0/sql/warehouses | jq '
  .warehouses[]
  | {name,
     keys: [(.tags.custom_tags // [])[].key],
     state}'

Compare each warehouse’s key list against the required 3.

What a warehouse tag can and cannot allocate

Honesty about the limit: warehouse-level tags attribute the whole warehouse to one owning team. They cannot split a single shared warehouse’s bill by who ran which query. For per-query attribution you need query history joined to billing system tables, or separate warehouses per team. The tag is still the right floor: it names the team accountable for the endpoint’s configuration and total, which is the party that decides whether finer-grained splitting is worth the added structure. Untagged, even that first question (“whose warehouse is this?”) has no answer.

Making the keys permanent

Add the 3 keys in the warehouse’s settings or the API payload that creates it, and put warehouse creation into infrastructure-as-code where review catches missing tags before the endpoint exists. Warehouses tend to be created rarely and live long, so a one-time backfill plus creation-time discipline keeps this finding permanently empty.