Kubecost × Metabase

How to build Kubernetes cost dashboards in Metabase

Kubecost is the Kubernetes cost monitoring platform (now IBM Kubecost) that allocates cluster spend to namespaces, workloads, and labels — built on the CNCF OpenCost project. Metabase is where you turn that billing data into shared, trustworthy cost dashboards. This guide covers two complementary paths: a lightweight API + CLI route that pulls live cost data via the Kubecost Allocation API and loads a CSV into Metabase with the Metabase CLI, and a durable pipeline route that lands Kubecost cost data in a database so you can build dashboards anyone can read.

Heads up: Metabase connects to databases and warehouses — it does not ship a native Kubecost connector. The good news: billing data is tabular and warehouse-friendly. Land line items or daily rollups in a database, model amortized vs. unblended cost once, and every dashboard downstream inherits the same definitions.

How do you connect Kubecost to Metabase?

Most teams combine both routes: quick answers through API exports and CLI uploads first, then recurring cost reporting on a warehouse-backed model.

1 · API + CLI route (AI-assisted)

Live cost answers in, quick analysis out

Script a scoped export against the Kubecost Allocation API (the OpenCost MCP server works too, from inside the cluster), write the result to CSV, then load it into Metabase as a ready-to-query table and model.

Best for
  • Quick questions such as "show me kubernetes cost by namespace and workload"
  • Loading Kubecost cost exports into Metabase in seconds
  • Spot-checks and one-off cost investigations without pipeline work
Trade-offs
  • Great for exploration, not governed month-end cost reporting
  • Use read-only credentials or scoped API keys wherever supported
  • CSV uploads are snapshots — refresh or move to the pipeline for history
2 · Pipeline route (warehouse-backed)

Durable cost dashboards with history

Land Kubecost cost data in a database or warehouse — via billing export, connector, or scheduled API pulls — then point Metabase at it.

Best for
  • Kubecost cost dashboards finance and engineering both trust
  • Joining cost with revenue, customers, and usage for unit economics
  • Long-run trends for kubernetes cost by namespace and workload and cost allocation by team and label
Trade-offs
  • You own the refresh schedule and the rollup grain
  • Model amortized vs. unblended cost once, in the warehouse layer
  • Tag and label hygiene decides how far allocation can go

What can you analyze from Kubecost data in Metabase?

  • Kubernetes cost by namespace and workload — built from allocation rollups and the related namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost data your sync exposes.
  • Cost allocation by team and label — built from allocation rollups and the related namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost data your sync exposes.
  • Idle and unallocated spend — built from allocation rollups and the related namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost data your sync exposes.
  • Cluster efficiency and rightsizing — built from allocation rollups and the related namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost data your sync exposes.
  • Shared cost distribution — built from allocation rollups and the related namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost data your sync exposes.

Which Kubernetes cost dashboards should you build in Metabase?

For: Platform engineers

Namespace and workload cost

Where cluster spend concentrates.

  • Cost by namespace, top 15 (bar)
  • Cost by workload within a namespace (table)
  • CPU vs. memory vs. storage cost split (stacked bar)
  • Cluster cost by day (line)
For: Platform, FinOps

Idle and efficiency

The gap between requested and used.

  • Idle cost share (number + trend)
  • Efficiency by namespace (bar)
  • Most over-provisioned workloads (table)
  • Unallocated and shared cost (number)
For: Team leads

Team allocation

Label-mapped cost ownership per team.

  • Cost by team label by month (stacked bar)
  • Unlabeled workload spend (number + trend)
  • Cost per team per cluster (table)
  • Shared cost distribution method note (text card)
For: Leadership

Trends

Cluster economics over time.

  • Cluster cost month over month (line)
  • Cost per namespace trend for the top 5 (line)
  • Rightsizing savings realized (number)
  • Cost joined to cloud bill share (combo)

How do you use the OpenCost MCP server with the Metabase CLI?

Pair the OpenCost MCP server with the Metabase CLI for fast, hands-on cost analysis. MCP works from inside the cluster for scoped lookups; scripted API exports cover everything else. the Metabase CLI's upload command loads CSV data into Metabase and creates a ready-to-query table and model.

Example workflow

  • Ask the API (or MCP) for yesterday's allocation rollups aggregated by namespace, with idle cost broken out.
  • Export the result as CSV, keeping stable IDs, accounts, services, tags, and dates.
  • Run mb upload csv to load it into Metabase as a table and model, then build questions and dashboards on top.

Be honest about the limits

  • API and MCP lookups are excellent for exploration, not scheduled reporting.
  • A CSV upload is a snapshot; refresh it with mb upload replace or move to the pipeline for real history.
  • Daily allocation windows are required for trends — the in-cluster API holds limited history unless you persist rollups externally.
  • mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up Kubecost MCP and the Metabase CLI?

OpenCost MCP serverofficial

Transport
In-cluster server over HTTP (port 8081)
Auth
Cluster access (kubectl port-forward or in-cluster networking)
Best for
Live scoped cost lookup and export

Metabase CLIofficial

Install
npm install -g @metabase/cli
Auth
mb auth login
Load data
mb upload csv --file data.csv
Requires
An uploads database (Admin → Settings → Uploads)
MCPExample MCP client config
{
  "mcpServers": {
    "opencost": {
      "type": "http",
      "url": "http://localhost:8081"
    }
  }
}

Kubecost itself ships no official MCP server (community wrappers exist — treat them as unofficial). The official-lineage option is the MCP server built into OpenCost, the CNCF project Kubecost is built on. The localhost URL assumes you first run kubectl port-forward svc/opencost 8081:8081 -n opencost to tunnel the in-cluster server to your machine; agents running inside the cluster skip the tunnel and use http://opencost.opencost.svc.cluster.local:8081 instead. Check your Helm chart version for whether opencost.mcp.enabled is on by default.

TerminalLoad a Kubecost CSV with the Metabase CLI
# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a allocation-rollups export — creates a table AND a model
mb upload csv --file kubecost-allocation-rollups.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file kubecost-allocation-rollups.csv

Can you generate a Kubecost dashboard with AI?

Yes. Use the prompt below with any assistant that can run shell commands (for the API export) and the Metabase CLI. It works end to end: if Kubecost cost tables already exist in Metabase it analyzes those; otherwise it pulls scoped, summarized data, loads it with mb upload csv, then builds the dashboard and caveats any metric that needs missing history.

Prompt for creating a Kubecost Kubernetes Cost Overview dashboard
Create a polished Metabase dashboard for Kubecost kubernetes cost analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help engineering, platform, and finance leaders understand namespace and workload cost, idle share, efficiency, and team allocation from Kubecost data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for kubecost tables and
  models). If durable Kubecost cost data is already present — a billing export,
  warehouse sync, or earlier upload — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export by scripting the Kubecost Allocation API:
  allocation rollups, plus namespaces and workloads, asset costs (nodes, disks, network), idle and unallocated cost.
  Prefer daily rollups by service, account, team, or namespace over raw line
  items. Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available fields, accounts,
services, tags or labels, and date ranges before creating trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Kubecost — it reads a database or CLI-uploaded tables.
- State whether costs are amortized, unblended, or net of credits — and never
  mix conventions in one card.
- A single CSV is a point-in-time snapshot: only build trend cards if there is
  a usable date column or multiple periods have been uploaded.
- Exclude or clearly separate credits, refunds, and taxes from usage cost.
- Only compute unit economics (cost per customer) when a customer-level
  dimension or tag actually exists in the data.

Dashboard title: Kubecost Kubernetes Cost Overview

Sections:
1. Executive summary: Cluster cost this month; Idle cost share; Efficiency;
   Unlabeled spend; MoM growth.
2. Allocation: Cost by namespace and workload; team labels; shared cost.
3. Efficiency: Idle cost; over-provisioned workloads; rightsizing wins.
4. Components: CPU vs. memory vs. storage vs. network cost split.
5. Trends: Cluster cost by month; top namespace trends; cloud-bill share.

Filters: Date range, Provider or Account, Service, Team, Environment, Tag.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data.

How do you sync Kubecost data into a database or warehouse?

For dashboards that need history and reliability, land Kubecost cost data in a database first, then connect Metabase to that database.

Connector options

  • Billing export or managed ETL — use the vendor's native export or a connector when one covers the objects you need.
  • Custom pipeline — use the Kubecost Allocation API for control over rollup grain, fields, and refresh cadence.
  • API/MCP + CSV — use this for quick exploration and one-off slices.

No managed connector exists — schedule Allocation API pulls (daily windows, aggregated by namespace or label) and land the JSON-flattened rollups in your warehouse. AWS documents this exact ETL-to-Athena pattern for its own Kubecost dashboards; a nightly script into Postgres works just as well.

Notes

  • Decide the rollup grain first (daily per service, account, and team) — it drives warehouse cost and every trend card.
  • Land raw billing tables first, then build clean Metabase models on top.
  • Normalize cluster, namespace, workload, label, window-start, and cost-component fields.

How should you model Kubecost data in Metabase?

Core tables

TableGrainKey columns
k8s_allocation_rollupsone row per namespace or workload per daywindow_start, cluster, namespace, workload, cpu_cost, ram_cost, pv_cost, network_cost, idle_cost, total_cost, efficiency_pct
k8s_assetsone row per cluster asset per daysnapshot_date, cluster, asset_type, name, cost_usd, labels
cost_allocationsone row per team per day (label-mapped)usage_date, cluster, team, environment, cost_usd

Modeling advice

  • Build a clean k8s_allocation_rollups model with common columns across clouds and tools, so multi-source dashboards don't fork definitions.
  • Keep amortized, unblended, and net-of-credits cost as separate, labeled columns — never let one card silently mix them.
  • Treat tags and labels as slowly changing: they apply from when they were added, and historical spend stays untagged.
  • Separate usage cost from credits, refunds, taxes, and support fees in the model layer, not in each card.

Which Kubernetes cost metrics should you track in Metabase?

MetricDefinitionNotes
Cost per serviceNamespace or workload cost per period, all components.Include idle and shared cost or totals won't reconcile.
Untagged spend rateUnlabeled workload cost over total cluster cost.Unallocated cost caps team-level accountability.
Cost growth rateMonth-over-month cluster and namespace cost change.Correlate with deploys and autoscaling events.
Cost per customerCluster cost mapped to tenants via labels.Needs a tenant label strategy decided up front.

What SQL powers Kubernetes cost dashboards in Metabase?

These assume a cleaned analytical model in a warehouse (PostgreSQL dialect). Adjust table and column names to match your pipeline.

Namespace cost with idle sharePostgreSQL

Direct cost, idle cost, and the idle percentage together.

SELECT
  namespace,
  ROUND(SUM(cpu_cost + ram_cost + pv_cost + network_cost), 2) AS direct_cost,
  ROUND(SUM(idle_cost), 2) AS idle_cost,
  ROUND(
    100.0 * SUM(idle_cost)
    / NULLIF(SUM(cpu_cost + ram_cost + pv_cost + network_cost + idle_cost), 0),
    1
  ) AS idle_share_pct
FROM k8s_allocation_rollups
WHERE window_start >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY namespace
ORDER BY direct_cost DESC;
Least efficient workloads by costPostgreSQL

Rightsizing candidates: low efficiency, real spend.

SELECT
  workload,
  namespace,
  ROUND(AVG(efficiency_pct), 1) AS avg_efficiency_pct,
  ROUND(SUM(total_cost), 2) AS cost_30d
FROM k8s_allocation_rollups
WHERE window_start >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY workload, namespace
HAVING SUM(total_cost) > 100
ORDER BY avg_efficiency_pct ASC
LIMIT 20;
Unlabeled cluster cost share by monthPostgreSQL

Label-mapped allocation rows with no team owner.

SELECT
  date_trunc('month', usage_date) AS month,
  ROUND(
    100.0 * SUM(cost_usd) FILTER (WHERE team IS NULL)
    / NULLIF(SUM(cost_usd), 0), 1
  ) AS unlabeled_cost_pct
FROM cost_allocations
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing Kubecost in Metabase?

Mixing amortized, unblended, and net-of-credits cost in one dashboard.→ Pick the convention per card and label it. Trends computed on one basis and totals on another will never reconcile — and finance will notice.
Ignoring idle and unallocated cost.→ Namespace costs that exclude idle capacity understate the bill by the exact amount nobody wants to own. Show idle share explicitly and decide how shared cost is distributed.
Treating allocation as invoice-grade truth.→ Allocation splits measured usage across workloads on top of assumptions about nodes and shared resources. Reconcile cluster totals against the cloud bill monthly.
Building dashboards from live MCP lookups only.→ MCP is useful for exploration; durable cost dashboards need a database-backed model with history.

Related analytics

Related dashboards

Related integrations

FAQ

Does Metabase connect natively to Kubecost?
No. Metabase reads databases and warehouses. Land Kubecost cost data in a database first — via billing export, connector, or API pipeline — or upload a CSV with the Metabase CLI, then build Metabase models and dashboards on top.
Should Metabase replace Kubecost?
No — they answer different questions. Kubecost is built for cost operations: rate optimization, recommendations, and native views. Metabase is where you build governed, shareable cost reporting for the whole company, and join spend with revenue, customers, and product usage for real unit economics.
Kubecost or OpenCost — which does this guide assume?
The data model is identical — Kubecost is built on the CNCF OpenCost project, and both expose the same Allocation API shape. Kubecost (now IBM Kubecost) adds savings insights, unified multi-cluster views, and enterprise features; OpenCost adds an MCP server. The warehouse pattern in this guide works with either.
How do I keep allocation history beyond the API window?
Persist it yourself: schedule a daily Allocation API pull at namespace and workload grain and append it to a warehouse table. The in-cluster store isn't built for long-run history — a year of daily rollups in Postgres or Athena is small and answers every trend question.