Investigation trails

One row = a cloud's usage totals for the window, split by record_type. The columns that matter are net_usage_quantity (the true net, corrections already applied) versus original_usage_quantity/retracted_abs_quantity/restatement_usage_quantity (how much of that net was corrected after the fact) - this is a trust/QA check on the billing data itself, not a cost or waste signal.

• if for the same net-corrected totals broken out by SKU/workspace→The Base Billing Rollup
• if for the net totals by product line→Where the Money Goes by Product

One row = a day + cloud + SKU + product + usage type/unit's usage, priced at list. The columns that matter are net_usage_quantity (the native-unit volume) and net_list_cost (usage_quantity x the list rate) - this is a pre-discount estimate, not what you actually pay.

• if for a DBU-only actual-vs-list comparison→Discount Realization by SKU (actual vs list)

realization ratio at/above :warn_realization_ratio (WARN) or :crit_realization_ratio (CRITICAL) - you are paying close to list price on that SKU; or either cost column is NULL (NOT_ASSESSED - a priced-coverage gap, not $0).

• if for the underlying raw price rows behind this comparison→Your List-Price Basis by SKU

• see also→Dollarizing DBUs at List Price

One row = a SKU's price at a point in time. The columns that matter are pricing_default (the list rate, cast to STRING because pricing.default is a high-precision decimal) and price_end_time (NULL means this is the currently active price for that SKU/cloud/currency).

• if for the full raw pricing struct including effective_list and promotional→The List-Price Rate Book

• see also→Discount Realization by SKU (actual vs list)

One row = a SKU's price at a point in time, with the full pricing struct preserved as JSON. The columns that matter are pricing_default (the list rate) and price_end_time (NULL means this is the currently active price) - pricing_effective_list_json and pricing_promotional_json carry the raw structs for you to parse yourself.

• see also→Discount Realization by SKU (actual vs list)

cluster_source IN ('UI','API') (WARN), especially with est_usd_list_share at/above :crit_share_usd (CRITICAL) - a job pinned to an always-on interactive cluster (field heuristic). The trailing NOT_ASSESSED summary row counts runs dropped for null compute_ids; do not read those as "clean".

• if to dollarize the same jobs' DBUs→Per-Job DBU Cost Ranking
• if these jobs also fail→Failing Jobs Ranked by Wasted DBUs
• if the shared cluster sits idle between runs→Idle Classic Clusters, Ranked

net_usage_quantity at/above :warn_job_dbus_per_day (WARN) or :crit_job_dbus_per_day (CRITICAL) DBUs/day - field heuristic; a job that is consistently in-band and just large may be fine, a job whose per-run cost keeps climbing is the one to open first.

• if distinct_runs is high relative to net_usage_quantity - retries may be inflating the cost→Job Failure Breakdown by Root Cause

• see also→Job Tasks On All-Purpose Compute

failed_run_rows at/above :warn_failed_run_rows (WARN) or :crit_failed_run_rows (CRITICAL) for a single termination_code - field heuristic; one code dominating points at a systemic cause, not one-off flakiness.

• if for the account-wide termination_code breakdown→Job Failure Root-Cause Breakdown
• if for the DBUs each failing job is burning→Failing Jobs Ranked by Wasted DBUs

One row = a (workspace, termination_code) combination in the window. Use run_rows / distinct_runs to see which termination reasons dominate before drilling into the specific failing jobs.

• if drill into the DBU cost of jobs terminating this way→Failing Jobs Ranked by Wasted DBUs

• see also→Job Failure Breakdown by Root Cause

failed_runs at/above :warn_failed_runs or wasted_dbus_proxy at/above :warn_wasted_dbus (WARN); either at/above :crit_failed_runs / :crit_wasted_dbus (CRITICAL) - field heuristic.

• if to see how many attempts each failing run actually took→Flapping Jobs That Retry

• see also→Job Failure Root-Cause Breakdown

total_retries at/above :warn_total_retries (WARN) or :crit_total_retries (CRITICAL) - field heuristic; a job where runs_with_retry is close to distinct_runs is retrying on (almost) every run, which usually points at a systemic cause.

• see also→Failing Jobs Ranked by Wasted DBUs
• see also→Job Failure Root-Cause Breakdown

status = WARN at/above :warn_runas_events, CRITICAL at/above :crit_runas_events - field heuristic; also treat a ZERO-ROW result with suspicion rather than relief - see caveats.

• if check if the same run_by identity also touched admin roles→Who Changed Permissions, From Where
• if see what the run_as identity can do→Who Holds Which Grants

status = WARN at/above :warn_admin_events, CRITICAL at/above :crit_admin_events - field heuristic; also worth a look whenever distinct_source_ips is unusually high for one actor.

• if see what that actor's role change actually granted→Who Holds Which Grants

• see also→Run-As Privilege Escalation Watch

One row = an object scope (TABLE or CATALOG) x privilege type x grantee, rolled up. The columns that matter are grant_count (how many individual grants) and distinct_objects (how many different tables/catalogs that grantee touches).

• if schema/connection/credential/external-location grants→Grants on Schemas and Integrations

• see also→Run-As Privilege Escalation Watch

One row = an object scope (SCHEMA, CONNECTION, CREDENTIAL, or EXTERNAL_LOCATION) x privilege type x grantee, with a grant count. Use it to see who holds broad integration-level access beyond plain table/catalog grants.

• see also→Who Holds Which Grants
• see also→Run-As Privilege Escalation Watch

pct_of_warehouse_exec_ms at/above :warn_wh_share (WARN) or :crit_wh_share (CRITICAL) - one statement shape eating a large share of a warehouse's execution time (field heuristic).

• if to roll repeat shapes up by fingerprint→Heaviest Query Shapes, Grouped by Fingerprint
• if read_files far exceeds pruned_files→Are Your Scans Skipping Files?
• if spilled_local_bytes is high→Disk Spill Memory-Pressure Hotspots

total_exec_ms at/above :warn_total_hours (WARN) or :crit_total_hours (CRITICAL) cumulative hours - a hot repeated shape (field heuristic). High runs + low avg_exec_ms means fix the caller (frequency / caching); high avg_exec_ms means tune the statement.

• if a hot shape scans far more files than it prunes→Are Your Scans Skipping Files?

• see also→Your Heaviest Statements, Ranked

pruning ratio below :warn_prune_ratio (WARN) or below :crit_prune_ratio (CRITICAL) - field heuristic; a stable low ratio on the same table/warehouse combination over several days is the real signal, not one bad day.

• if the same reads are also shuffle-heavy→Shuffle And Small-Files Hotspots

shuffle_read_bytes_sum at/above :warn_shuffle_gb GB (WARN) or :crit_shuffle_gb GB (CRITICAL), OR average written-file size below :warn_avg_file_mb MB (WARN) or :crit_avg_file_mb MB (CRITICAL) - field heuristics; either signal alone is enough to flag the row.

• if the same warehouse also spills - shuffle and spill often co-occur→Disk Spill Memory-Pressure Hotspots

spilled_local_bytes_sum at/above :warn_spill_gb GB/day (WARN) or :crit_spill_gb GB/day (CRITICAL) - field heuristic; sustained daily spill on the same warehouse is the real signal.

• see also→Shuffle And Small-Files Hotspots
• see also→Your Heaviest Statements, Ranked