Serverless usage policies: tag your Databricks bill by team

--- title: "You can finally see which team owns the serverless part of your Databricks bill. Most people have not turned it on." slug: databricks-serverless-usage-policies-cost-attribution author: Insignyx date: 2026-06-22 tags: [databricks, cloud-cost, finops, serverless, cost-attribution, billing] description: "Serverless usage policies went to Public Preview in May 2026. They tag serverless compute DBUs by team or project on the billing records. The lever has been sitting in your workspace admin for weeks and almost no one is using it." ---

# You can finally see which team owns the serverless part of your Databricks bill. Most people have not turned it on.

By Insignyx · ~5 min read · Cloud Cost Playbook

We run a small ritual at the start of cost audits. We open the last month's invoice, then we open the system.billing.usage table, and we ask the simplest question in FinOps:

"Which team is responsible for this line item?"

For classic compute, the answer usually arrives in five minutes. There are cluster tags. There are job tags. There is enough metadata on the row to point a finger at whoever spawned the cluster. For serverless, the answer mostly does not exist.

The mix shifts these days. A growing slice of the bill is serverless — Lakeflow jobs, serverless notebooks, Lakebase, model serving, Spark Declarative Pipelines, Databricks Apps. We see mid-market workspaces where serverless is 40-60% of the monthly DBU spend. On most of those rows, the billing record has the user who triggered the run, but nothing that ties it back to a budget. Cost-attribution theatre.

In late May 2026, Databricks shipped a feature that fixes this for serverless. It is in Public Preview. It is sitting in your workspace admin settings today. Almost nobody we have talked to has noticed.

It is called a serverless usage policy.

What it actually is

A serverless usage policy is a named bundle of custom tags. You assign the policy to a user, group, or service principal. From that point forward, every serverless compute run initiated by that identity carries those tags on its billing record.

Concrete shape:

- You make a policy called data-platform-team with the tags team=data-platform and cost_center=eng-101. - You add another called marketing-analytics with team=marketing and cost_center=mkt-22. - On the policy page, you grant User permissions to the relevant person or group. - The next time that person runs a serverless notebook or Lakeflow job, the billing row has those tags in custom_tags.

That is it. Not magic. Just plumbing.

The docs page for it is "Attribute usage with serverless usage policies," last updated May 27, 2026, at docs.databricks.com/aws/en/admin/usage/budget-policies. The status on the top of the page reads Public Preview, which means it works today and APIs are stable enough to put into production, but the fine details could shift.

Caption: Where the policy lives, where it gets attached, and where it shows up on the bill. Visual by Insignyx.

Why your serverless bill has been a black box

Without these policies, your serverless billing rows typically have:

- usage_type — serverless jobs, serverless SQL, serverless notebooks, etc. - sku_name, usage_quantity, usage_start_time, the usual - user_identity — the human or service principal who triggered the run

They do not, by default, have anything connecting back to the team that owns the work. If you tried to charge back by team, you were stuck with one of three workarounds:

1. Naming conventions. "Every Lakeflow job name starts with team_X_." Parse the prefix. Hope nobody renames anything. 2. Per-team workspaces. Spin up a whole workspace for each team. Painful, expensive, and it duplicates everything from Unity Catalog down. 3. Live with it. Most teams just live with it. Serverless cost shows up as a single line on the cost report titled "serverless jobs, $7,400" and everybody nods.

The serverless usage policy is what you wished cluster tags were for serverless, finally built out properly. You assign once, the tags propagate, chargeback works.

How to set one up

The doc walk-through is short. The whole thing is a ten-minute exercise per policy, if you are doing it in the UI.

1. Workspace admin settings. Click your username in the top bar → Settings → Compute → next to "Serverless usage policies" click Manage → Create.

2. Pick the custom tags. These are arbitrary key-value pairs. Spend a minute agreeing on a tag schema before you make 14 of these. We have seen teams run with team and env (dev / staging / prod). Some add cost_center so finance can land the charge on the same GL code they already use for AWS. Two to four tags per policy is plenty.

3. Scope the policy to workspaces. If you do not pick any workspaces, the policy is available account-wide. Useful, but you want to think about whether your staging clusters should carry team=data-platform-staging or inherit the prod-style tag from the same policy.

4. Grant User permissions. On the policy's Permissions tab → Grant access. Pick the user, group, or service principal. Pick User if they should attach it to their assets, Manager if they should be able to edit the policy.

5. Tell your users. If a user is assigned multiple policies, they pick one every time they create a notebook, job, pipeline, model serving endpoint, Lakebase instance, or Databricks App. The default is "whichever comes first alphabetically" — which at most companies I have seen, is whatever someone named "A-test" three years ago. Plan for that.

That is the entire UI flow. The Terraform path exists via the policies API; it is worth wiring if you have more than a handful of policies to manage.

Which tags should you pick

We have no strong opinion on your tag schema, but please pick one. Three tags that have held up across the dozen or so customers we have helped with this:

- `team` — owning team. team=data-platform, team=marketing, team=growth. This is the only tag that has to be there. - `cost_center` — finance-side GL code or cost-center id. Decouples your tag schema from your AWS / Azure / GCP cost-center setup. - `env` — dev / staging / prod. Lets finance give dev a hard look during quarter-end without bothering you on every prod row.

Two to four tags is the right count. Five feels like a tax. One feels like a missed opportunity.

What the billing record looks like after

Below is the kind of output you can pull from system.billing.usage once a couple of policies are in place. We have used a date range of a recent 7-day window and filtered to serverless rows to keep the example legible:

-- Cost attribution for serverless usage, grouped by the
-- custom_tags added by serverless usage policies.
SELECT
  record_id,
  usage_start_time,
  identity_metadata.run_as,
  sku_name,
  usage_quantity,
  custom_tags
FROM system.billing.usage
WHERE billing_origin_product = 'SERVERLESS'
  AND usage_start_time >= current_timestamp() - INTERVAL 7 DAYS
ORDER BY usage_start_time DESC
LIMIT 20;

The two columns that earn their keep are custom_tags (your serverless usage policy tags) and identity_metadata.run_as (the dataset the principal is acting under). Bring those together and you can group spend by team. The custom_tags column stores tags as a map<string,string>, so flatten it with custom_tags:team or custom_tags:cost_center in your BI tool of choice.

Caption: We ran this query on a sample workspace after two weeks of policies in place. Sorted by `custom_tags:team`. Numbers are illustrative. Visual by Insignyx.

A small note on what is not in your tagged rows yet: classic compute. The docs are explicit that the policy propagates tags only to serverless usage rows. Cluster tags remain the right tool for classic compute. If you split the bill roughly 50/50 between classic and serverless, you need both. Run them in parallel.

What this looks like in dollars (with caveats)

This is the part where we have to be careful ladies and gentlemen. We do not have a controlled study of serverless usage policy rollouts. The savings lever is not "the policy makes your serverless bill go down" — it is "the policy makes the line items legible, then your team-level accountability does the work." Even so, the directional pattern from our cost audits is consistent enough to share.

For a mid-size workspace where serverless is roughly $5,000-$8,000 / month and FinOps has been operating off one big "serverless jobs" line:

The cap is roughly your credit-card-blather level of spend: $5,000-$10,000 in savings on a $50,000 serverless bill is not unusual.

Five things to know before you roll out

1. The policy is in Public Preview. As of the May 27, 2026 docs update. The contract is not "1.0 GA," it is "feature is on, APIs are usable, edge cases may shift." Pin a version if your team is conservative.

2. Notebooks, jobs, pipelines, endpoints, Lakebase, apps — all in scope. Lakeflow Spark Declarative Pipelines do get tagged, but with a caveat: a pipeline triggered by a job does not inherit the job's policy. You set the policy on the pipeline itself. Twice. Yeah.

3. Existing assets do not auto-assign. When you grant a user access to a policy, that does not retroactively apply it to assets they already own. You must manually update each existing notebook, job, or pipeline in the UI. Plan an afternoon for the migration if you have hundreds of existing serverless jobs.

4. Alphabetical default will confuse your users. If a user has multiple policies and forgets to pick one when launching a notebook, the system picks the first one alphabetically. Pick the team one starts with "a-" if you want a quiet default.

5. It does not tag classic compute. Add custom_tags for that separately, or rely on cluster tags.

What this list is missing on purpose

Same honesty rule as the last two posts:

- *Tag policy on the account* still beats this for governance. Serverless usage policies live in workspace admin scope. Account-level tag enforcement (when it lands) will subsume this. Until then, the workspace version is what you have. - This does not reduce DBUs. It surfaces them. The savings come from the human and FinOps loop that follows, not from the feature itself. - It is a Public Preview. Re-read this every quarter. The contract can shift. If you are pinning a hard schema in Terraform, watch the API version. - Committed Use Discounts still beat all of this at scale.** A 1- or 3-year DBU commit is the bigger number. The cost attribution work is independent of that conversation — you want both before you go to procurement.

One last honest caveat

This is a plumbing feature. It does not, by itself, fix anything. It puts a label on a line item. The line item still has to be looked at by a person who can decide what to do about it.

The reason we still recommend it on every audit: without labels, nobody reads the line items. People read dashboards. Dashboards need groupings. Cost-attribution tags are how you group a serverless bill that, by default, refuses to be grouped.

Setup time: an afternoon, including the early-2026 awkwardness of "your user has 14 policies and the alphabetical default is whatever someone named A-team six months ago." Recovery time: another afternoon, retro-tagging existing assets.

If your monthly invoice has started scaring you, and the line items have stopped scaring you, this is a five-hour fix worth the five hours.

About Insignyx

We help mid-market teams get their Databricks and Snowflake bills back under control without rebuilding the warehouse. If your monthly invoice has started to scare you, we should talk.

👉 insignyx.com

Sources and footnotes

- Serverless usage policies (Public Preview): docs.databricks.com/aws/en/admin/usage/budget-policies — page last updated May 27, 2026. - Tags from a serverless usage policy propagate to system.billing.usage in the custom_tags column. Verified on the same docs page. - Databricks pricing for DBU rates by region (re-verified): databricks.com/product/pricing. - Cluster tags remain the right tool for classic compute cost attribution. Same docs page notes the limitation that serverless usage policies do not apply tags to classic compute.