# SQL Warehouse Missing Cost-Allocation Tags

> SQL warehouses are multi-tenant by design: analysts, dashboards, and BI tools from several teams share 1 endpoint, and the warehouse bills as a single line. Tags carrying team, environment, and cost-center are the key for allocating that shared spend, so ZopNight flags running warehouses missing any of the 3.

Source: https://zop.dev/integrations/databricks/recommendations/sql-warehouse-missing-cost-allocation-tags
Updated: 2026-08-19

---

## 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

```bash
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.