Fixed fee · Two weeks · Scorecard either way
Find the Databricks spend that is not working for you
Workspaces drift. Clusters get sized for a load that never arrived, jobs that should be serverless still run on all-purpose compute, schedules outlive the person who wrote them, and Unity Catalog coverage stops halfway. Two weeks, a fixed fee, and a scorecard whether or not you do anything about it.
- Length
- Two weeks
- Who it is for
- Teams already on Databricks whose bill is growing faster than the work
- Bench
- 80 Databricks-certified engineers
What we inspect
- Compute and workload cost patterns, from system tables where you have them
- Cluster and warehouse sizing, and which jobs are serverless candidates
- Job failure and retry patterns, and what they cost in reruns
- Unity Catalog coverage and privilege hygiene
- Orphaned compute and schedules nobody owns
- Model serving and Unity Gateway spend, where they are in use
What you get
- 01A written scorecard with findings ranked by severity
- 02Estimated savings against each finding, with the reasoning shown
- 03A thirty, sixty and ninety day remediation order
- 04A fixed-scope proposal for the remediation, if you want us to do it
Where a Databricks health check starts
With the bill broken down by what produced it. Every DBU a workspace consumes lands in system.billing.usage with the SKU, the date, the product that originated it (JOBS, SQL, DLT and so on) and the job, cluster or warehouse behind it. Joined to system.billing.list_prices on cloud, SKU and the price's validity window, that becomes spend by product, and it's the first table we read.
Two things it won't tell you on its own. It prices at list, so the figure sits above what you pay under a committed-use contract, and it's the shape that matters rather than the total.
Databricks' own documentation also says jobs run on all-purpose compute or on SQL warehouses aren't billed as jobs, so they drop out of job cost attribution entirely. A job pinned to an interactive cluster never appears on a "most expensive jobs" list. It shows up as all-purpose spend that nobody can explain, which is why it survives so many cost reviews.
SELECT u.billing_origin_product,
u.sku_name,
ROUND(SUM(u.usage_quantity * lp.pricing.default), 2) AS list_cost
FROM system.billing.usage AS u
JOIN system.billing.list_prices AS lp
ON u.cloud = lp.cloud
AND u.sku_name = lp.sku_name
AND u.usage_start_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_end_time <= lp.price_end_time)
WHERE u.usage_date >= date_sub(current_date(), 30)
GROUP BY u.billing_origin_product, u.sku_name
ORDER BY list_cost DESC;Checked on 11 October 2026 against Databricks: billable usage system table, Databricks: pricing system table, Databricks: monitor job costs with system tables and Databricks: jobs system tables.
What happens in the two weeks
01
Read-only access, and a scope if you need one
Read access to the workspace and to the system tables you have enabled. No production data and no write access. If security wants a named scope first, we write it before anything is granted.
02
Spend by product, then by workload
The billing query above, then the same spend broken down by job, warehouse and cluster through usage_metadata, so a large number becomes a short list with owners.
03
Job reliability
From system.lakeflow.job_run_timeline, which keeps 365 days of runs with a result_state (SUCCEEDED, FAILED, TIMED_OUT and the rest) and a termination code. Runs that fail and retry until they succeed look like successes on a dashboard and cost like several runs on the bill.
04
Compute sizing and serverless candidates
Jobs still on all-purpose clusters, autoscale floors set during the pilot, warehouses sized for month-end and idle the rest of the month, and which scheduled jobs would cost less as serverless.
05
Unity Catalog coverage and privilege hygiene
Which schemas never left hive_metastore, which principals hold ALL PRIVILEGES, and whether grants go to groups or to people. The information schema can't see hive_metastore, so that part is listed separately.
06
Orphans, then the scorecard
Schedules and compute nobody claims, and model serving or Unity Gateway spend where it's in use. Then the written scorecard, ranked by severity, with an estimated saving and the reasoning against each finding and a thirty, sixty and ninety day order.
Seven questions your workspace can answer this afternoon
Most of this can be answered from your own workspace in an afternoon, and the answers make the first conversation shorter. The cost dashboard said the workspace was fine is Ihor Seleznov's account of what these checks turn up. The Databricks readiness self-assessment covers the wider platform in ten questions.
For one job, warehouse or serving endpoint at a time, the Chrome extension we built for Databricks shows what it cost over the last 30 days at list price, on the page you already have open.
Run these against your own estate
- Can someone on your team query system.billing and system.lakeflow today?
- What share of last month's spend was all-purpose compute, and how much of that was scheduled jobs?
- Which jobs failed or retried most in the last 30 days, and does anyone own them?
- Which schedules belong to people who've left?
- Which warehouses run all week at a size chosen for month-end?
- How many schemas are still in hive_metastore?
- Which principals hold ALL PRIVILEGES, and why?
What makes it faster
The scorecard is the audit. When you want us to stay and fix what it found, Radar is what we use: declared SLOs per workload, and every restart or reroute written down as a governed action. A two in the morning fix keeps an audit trail instead of vanishing into a terminal history.
Clients we have done this for
Automotive / Fintech
SWBC
Credit union loan officers quote and book vehicle protection in SWBC's LOSExpress alongside a member's auto loan, but quoting was slow and new staff took too long to learn it. After gathering feedback from SWBC's staff and customers, our engineers and designers rebuilt one of its modules as a single-page application on a new design system. Orders processed doubled, and each loan officer now spends half as long on an order.
Automotive / Fintech
Location Services
Location Services' repossession platform automates assignment intake, so fewer people handle each case, and our engineers built it with the company's own technology team. When it was time to leave Synapse and SQL Server, we moved it onto Databricks in waves that could each be rolled back, and the rules engine that checks every assignment came through unchanged.
FAQ
Questions about Health Check
What is a Databricks Health Check?
A fixed-fee two-week workspace audit. We read compute cost, job reliability and Unity Catalog coverage, and we hand you a severity-ranked scorecard with estimated savings and a thirty, sixty and ninety day order. The page is /databricks/health-check. If you then want the remediation run as governed actions rather than a ticket pile, that work sits on TechFabric Radar.
What access do you need?
Read access to the workspace and, where you have them, system tables. We do not need production data, and we do not need write access to run the audit. If your security process needs a named scope, we will write one before anything is granted.
What if you find nothing worth fixing?
Then you have a scorecard saying so, which is worth having in front of a CFO asking about the bill. The fee is fixed either way. We would rather tell you the platform is healthy than manufacture findings to justify a remediation.
Do we have to use you for the remediation?
No. The scorecard is yours and it is written so your own team can act on it without us. We quote the remediation separately, and plenty of clients do the straightforward parts themselves and bring us in for the rest.
How is this different from the cost dashboard we already have?
A dashboard tells you what you spent. This tells you which of it bought nothing, why, and what to change. That judgement is the deliverable, and it comes from engineers who have run these platforms rather than from a billing export.
The other ways to start
Two weeks
Migration Readiness Sprint
Teams with a migration approved and a scope nobody can defend yet
Six weeks
Lakehouse Launchpad
Teams modernising off a legacy warehouse, or stalled after a pilot
Two to four weeks
Genie Accuracy
Teams whose natural-language analytics lost the room