kubera — optimization dashboard

Clusters

–

connected · discovered

Estate entities

–

AWS resources edged to clusters

Incidents (24h)

–

alarm-initiated diagnoses

Changes (24h)

–

ledger events

Recoverable waste

–

→ Cost

Needs attention — newest alarm-initiated diagnoses View all ›

–

Recent changes View all ›

–

Change ledger — who changed what, when, through which door

Scope: the selected cluster plus everything currently edged to it — its AWS resources and the databases/queues/vendors its workloads talk to. Sources: CloudTrail, the in-cluster watch module, and kubera's own actuations. Rows are hash-chained; the chip says whether the chain recomputed cleanly.

–

Received	Alarm	Entity	Symptom class	Mapped	Top cause
Loading…

Incidents — each alarm becomes a diagnosis: top-ranked causes with evidence

–

Standing risks — trends projected to cross a floor while there's still time to act

When a diagnosis detects a depletion trend (storage draining, burst balance falling, connections climbing), kubera projects when it crosses its floor — e.g. “free storage reaches 0 by Jul 13 20:26Z”. Risks below are extracted from recent diagnoses; a standing sweep that finds them before an alarm fires is on the roadmap.

–

Get started — from zero to a graded, shareable fleet report in three steps · about 15 minutes, most of it the CloudFormation stack deploying

–

Findings

–

across – workloads

Critical

–

fix first

High

–

security + reliability

Unowned workloads

–

no team label resolved

Posture findings — scored from the specs the read-only agent already pushes; CIS / Polaris / kube-linter cited

–

Environments — capacity share is requested-cores (cost proxy until per-workload dollars land)

–

Auto-sleep candidates — non-production namespaces requesting capacity nobody uses (waste ≥ 60%)

–

Kubernetes — clusters and workloads matched against the vendor's live entity set

–

AWS resources — joined by ARN tag only; a name join on AWS would guess

–

GitHub — powers remediation PRs, lead time, and post-deploy verdict comments

–

Slack — failed/degraded verdicts and remediation PRs, pushed to a channel

–

weekly digest, every

LiteLLM gateway — read-only spend report; kubera never sits in the request path

–

Model providers — OpenAI / Anthropic admin usage APIs (tokens by model, read-only)

–

Keys are sealed (AES-GCM) before they reach storage and never round-trip — status shows only that a key is set.

New Relic — telemetry-coverage check: entity-searches the account to verify data actually arrives (Telemetry page)

–

Read-only NerdGraph entity search — kubera never writes to New Relic. The key is validated with a live call when you save (a bad key is rejected on the spot), and the region is detected automatically unless you pin it.

Findings

–

across – resources

Critical + high

–

fix first

Alert coverage

–

resources with paging alarms

Production gaps

–

env-weighted severity

Alert coverage — which resources have an alarm on the metric that pages you

–

Findings — from the agentless sweep; environment classified by tags and naming

–

GPU workloads

–

with accelerator requests

GPUs requested

–

across all replicas

Findings

–

config-derived

Utilization

not yet graded

needs GPU telemetry (DCGM)

GPU inventory — every accelerator ask in the fleet, from the specs the agent already pushes

–

LLM consumers — spec-derived (env names + images)

–

Per-service token usage — OTel GenAI spans: the source that says WHO spends, joined to teams

–

AI adoption & impact — deploys banded by commit evidence, DORA outcomes compared across bands; correlational, never causal

–

Accelerator findings — the most expensive waste in the cluster is a GPU waiting on its pod

–

Team scorecards — graded per team: security & reliability from config posture, efficiency from observed waste

–

self-contained HTML — save or forward it

Realized savings

–

View savings ›

Proposed savings

–

Review & approve ›

CPU utilization

–

Nodes & capacity ›

Memory utilization

–

Nodes & capacity ›

Nodes

–

See node inventory ›

Workloads (discovered)

–

Open workloads ›

Est. compute cost

–

list pricing

CPU overprovisioned

–

allocatable vs requested

Cluster	Status	Mode	Agent health	Nodes	Workloads	CPU util	Mem util	Est. cost/mo	Realized/mo	Proposed/mo
Loading…

Requested vs actual usage over time — is the gap closing?

Requested Used (P90/P95)

CPU —

Memory —

You can save

–

Monthly savings

–

Annual savings

–

Already saved (banked)

–

Fleet compute cost — estimated from allocatable capacity at list pricing

Current (estimated): –/mo

With kubera applied: –/mo

Where the savings come from

Lever	How	Monthly	% of bill
Loading…

◉ Reliability ⛨ Security soon $ Cost soon

Cluster	Version	Spot	Telemetry	Evidence	Findings	Exact $/yr
Loading…

Current month spend (est.)

–

Monthly forecast (est.)

–

Avg daily cost (est.)

–

Blended rate

–

per vCPU-month

Daily compute cost — estimated from allocatable capacity at list pricing; custom pricing/discounts not reflected

Per cluster

Cluster	MTD (est.)	Forecast month end (est.)
Loading…

Month to date

–

vCPU-days

Forecast (month end)

–

vCPU-days

Last month

–

vCPU-days

Daily billable vCPU — per cluster, daily max of allocatable managed vCPU

Per cluster

Cluster	Current vCPU	Metered days	vCPU-days (MTD)	Forecast (month end)
Loading…

This is exactly what the meter bills from: for each day, the maximum allocatable vCPU across your managed nodes — measured server-side from agent snapshots, never self-reported.

Workload efficiency — requested vs used (waste heatmap) — discovery findings show immediately; savings estimates sharpen after ~1h of metrics

	Workload	Kind	CPU req→used	Waste	Mem req→used	Waste	Recommended	Savings/mo	Mode	Phase
Loading…

Activity — every change, human or machine, in one stream

Time (UTC)	Initiated by	Action	Target	Detail	Savings/mo
Loading…

Human actions come from the org audit trail (approvals, membership, tokens); kubera's own actions come from the clusters' change events — applied right-sizes, and guardrail rollbacks. Every approved right-size shows the monthly savings it unlocked.

Automation policies — Karpenter provisions the nodes; kubera tunes what runs on them

Create a policy from a template:

Every card edits the cluster's OptimizationPolicy directly over kubera's outbound-only command channel — what you see here is what the cluster runs. Prefer GitOps? Each card can show the YAML to commit instead. Policy edits land in the audit trail with the exact fields changed.

Nodes & capacity — what you're actually renting, and where it goes

Node	Instance	Capacity	Arch	Zone	CPU (alloc/cap)	Memory (alloc/cap)	Est. cost	Age
Loading…

Node prices are modeled from list pricing (spot at a discount factor) — the agent reads only Kubernetes labels, no cloud credentials. Capacity minus allocatable is the platform overhead the kubelet and system daemons reserve before a single pod is scheduled.

Hibernation — scale a non-prod cluster to zero nodes on a schedule, no cloud credentials

How hibernation works — annotations & exemptions

kubera scales every non-exempt workload to zero, recording each one's replica count on the workload itself (kubera.io/pre-hibernate-replicas) — Karpenter removes the empty nodes. Resume restores the recorded replicas and Karpenter provisions. kube-system, kubera-system and karpenter are always exempt; annotate anything else with kubera.io/hibernate-exempt=true to keep it running. Because the state lives on your workloads, you can inspect or resume any of them with plain kubectl.

Schedule enabled Sleep from (UTC) Wake at (UTC)

A missed transition heals on the next agent snapshot — the schedule is a desired state, not a cron that can be missed. Every transition lands in the change history.

Node consolidation candidates

Node	Waste	Reason	Savings/mo
Loading…

	Node	Verdict	Why	Savings/mo
Loading…

Eval scenarios — what kubera is validated against; run the runnable ones on your own cluster

Run kubera's own eval scenarios (▶ marked) against YOUR cluster — same workloads, same oracles as our lab harness. Results report back to this panel. Needs the kubera agent installed.

Scenario	Category	Proves	Oracle (how we know it passed)	Your clusters
Loading…

Welcome to Kubera

Connect a cluster

Connect cluster

Your estate is empty

Needs attention — newest alarm-initiated diagnoses View all ›

Recent changes View all ›

Change ledger — who changed what, when, through which door

Turn your CloudWatch alarms into ranked root causes

Alarm signals — every CloudWatch alarm kubera received, newest first + Add more alarms

Incidents — each alarm becomes a diagnosis: top-ranked causes with evidence

Standing risks — trends projected to cross a floor while there's still time to act

Get started — from zero to a graded, shareable fleet report in three steps · about 15 minutes, most of it the CloudFormation stack deploying

Posture findings — scored from the specs the read-only agent already pushes; CIS / Polaris / kube-linter cited

Environments — capacity share is requested-cores (cost proxy until per-workload dollars land)

Auto-sleep candidates — non-production namespaces requesting capacity nobody uses (waste ≥ 60%)

Kubernetes — clusters and workloads matched against the vendor's live entity set

AWS resources — joined by ARN tag only; a name join on AWS would guess

GitHub — powers remediation PRs, lead time, and post-deploy verdict comments

Slack — failed/degraded verdicts and remediation PRs, pushed to a channel

LiteLLM gateway — read-only spend report; kubera never sits in the request path

Model providers — OpenAI / Anthropic admin usage APIs (tokens by model, read-only)

New Relic — telemetry-coverage check: entity-searches the account to verify data actually arrives (Telemetry page)

Alert coverage — which resources have an alarm on the metric that pages you

Findings — from the agentless sweep; environment classified by tags and naming

GPU inventory — every accelerator ask in the fleet, from the specs the agent already pushes

LLM consumers — spec-derived (env names + images)

Bedrock token usage — per model, agentless via CloudWatch, 14-day window

Gateway token usage — via the LiteLLM proxy's spend report, read-only

Provider usage — OpenAI / Anthropic admin usage APIs, read-only, 14-day window

Per-service token usage — OTel GenAI spans: the source that says WHO spends, joined to teams

AI adoption & impact — deploys banded by commit evidence, DORA outcomes compared across bands; correlational, never causal

Model-mix recommendations — list-price arithmetic at your observed volume; run your evals before changing a route

Accelerator findings — the most expensive waste in the cluster is a GPU waiting on its pod

Team scorecards — graded per team: security & reliability from config posture, efficiency from observed waste

Welcome, there ●

Start optimizing your cluster with one kubectl apply

Get to your first savings — three steps · about two minutes of hands-on work

Fleet — clusters aggregated

Where the capacity goes — used vs reserved vs available

Requested vs actual usage over time — is the gap closing?

Fleet compute cost — estimated from allocatable capacity at list pricing

Savings over time — a stable trend beats a point-in-time claim Export CSV

Where the savings come from

Discover your EKS fleet — no agents, one read-only role

AWS connections — one read-only role per account; pending roles are probed every 60s + Add account

Discovered clusters

Daily compute cost — estimated from allocatable capacity at list pricing; custom pricing/discounts not reflected

Per cluster

Daily billable vCPU — per cluster, daily max of allocatable managed vCPU

Per cluster

Workload efficiency — requested vs used (waste heatmap) — discovery findings show immediately; savings estimates sharpen after ~1h of metrics

Activity — every change, human or machine, in one stream

Automation policies — Karpenter provisions the nodes; kubera tunes what runs on them

Nodes & capacity — what you're actually renting, and where it goes

Hibernation — scale a non-prod cluster to zero nodes on a schedule, no cloud credentials

Node consolidation candidates

Consolidation wizard — plan → review → execute; kubera drains, your provisioner removes

Eval scenarios — what kubera is validated against; run the runnable ones on your own cluster

Start optimizing your cluster with one `kubectl apply`

Savings over time — a stable trend beats a point-in-time claim

AWS connections — one read-only role per account; pending roles are probed every 60s