Labels & Attribution

Kubernetes labels are the most powerful tool for cost attribution at scale. CostPilot lets you map any label key to a meaningful business dimension, turning raw app.kubernetes.io/part-of=payments labels into “Team: Payments” in your cost reports.

Why label mapping matters

Without label mapping, costs are visible by namespace and workload — useful, but not enough for chargeback or team accountability. With label mapping, you can answer:

“How much did the Platform team spend this month?”
“What’s our production environment costing vs. staging?”
“Which cost centre should we bill for the ML training jobs?”

Setting up label mappings

Navigate to Settings → Labels. CostPilot automatically discovers all label keys it has seen across your cluster’s pods and surfaces them here.

For each label key you want to use as a cost dimension:

Enable it — toggle the label on
Set a display name — e.g. team → “Team”, cost-centre → “Cost Centre”
Choose a semantic role (optional) — marks the label as a standard dimension type

Semantic roles

Role	Label	Description
Team / Ownership	`TEAM_OWNERSHIP`	Engineering team or product owner
Environment	`ENVIRONMENT`	Deployment environment (prod, staging, dev)
Cost Center	`COST_CENTER`	Billing unit for chargeback and showback
Application	`APPLICATION`	Application or product name
Service	`SERVICE`	Microservice or component name
Custom	`CUSTOM`	Anything that doesn’t fit a standard role

Semantic roles affect how CostPilot presents and groups labels in reports and insights. For example, labels with the Environment role appear in environment comparison views; labels with Team / Ownership drive the chargeback export.

ℹ Note

You can configure multiple label mappings — one per role, plus additional Custom mappings. This means you can simultaneously track costs by team, environment, application, and any custom dimension your organisation uses.

Auto-discovery

CostPilot continuously scans newly observed label keys across your cluster. When it finds a new key, it appears in the Labels settings page as “Discovered” — you can then decide whether to enable it as a dimension.

ℹ Note

Label values are collected from pod metadata at the time of metric collection. If a pod’s labels change, the updated values are reflected in new metric records. Historical records retain the labels that were present when they were collected.

Label inheritance

CostPilot resolves labels at the pod level, not the Deployment level. In practice, Kubernetes propagates labels from Deployments and StatefulSets down to their pods automatically.

If you have pods without the labels you expect, check that your Deployment’s spec.template.metadata.labels includes the desired keys — not just metadata.labels on the Deployment resource itself.

Using labels in Cost Explorer

Once you’ve enabled label mappings, they appear in Cost Explorer’s dimension picker under their display names. Selecting “Team” as the dimension shows all your label values for that key as separate rows, each with their own cost breakdown.

You can combine label dimensions with filters: for example, view costs by Workload filtered to only the team=backend label.

Optimising label coverage

For accurate chargeback, aim for high label coverage — ideally every pod should have values for your key labels (Team, Environment, Cost Center).

CostPilot shows you label coverage statistics in the Labels settings page, including:

Coverage % — Percentage of pod-hours that had a value for this label
Unlabelled cost — How much spend cannot be attributed because this label is missing

Workloads without label values appear under (unset) in Cost Explorer, making it easy to identify what needs labelling.

✦ Tip

Start with the label that maps to engineering teams or product owners. This one change typically unlocks the most actionable cost attribution for most organisations.