Skip to content
Start free

Kubeadapt MCP

Investigate a cost increase

Ask an AI tool connected to Kubeadapt MCP why Kubernetes spend went up: what moved between two periods, which workloads drove it, and what an alert found.

Last updated

Ask your AI tool why spend went up and it compares two periods, ranks the clusters, namespaces or workloads that moved most in dollars, and drills into the biggest one. If a Kubeadapt cost alert fired, it can read the incident and check whether the change is real.

This example needs a connection with the Costs and carbon data kind. Questions about incidents also need Alerts, and questions about usage need Savings.

Ask

plaintext
Why did last week cost more than the week before? Which workloads drove the change?
plaintext
Our bill jumped on the 6th. Compare that day with the day before, by namespace.
plaintext
Compare September with August on the prod cluster by namespace, then show the workloads behind the biggest increase.
plaintext
Are any cost alerts open right now? What fired, and is the cost change real?
plaintext
Show the daily cost of the checkout deployment over the last 30 days. When did it start rising?
plaintext
Did checkout use more CPU and memory, or did only its requests go up?

What happens

ToolWhat it returns here
compare_costsBoth totals, the change in dollars and percent, and the rows that moved most by absolute dollar change, each marked new, gone or changed. Without dates it compares the last 7 complete days with the 7 days before.
query_costsThe period's spend grouped by workload, filtered to the namespace or cluster that moved, to find what drove the change.
get_cost_trendDaily spend for the organization, a cluster, a namespace or one workload, to find the day a change began.
get_usage_historyCPU and memory used against requests and limits for a workload, namespace or node, and whether use rose or fell over the window.
list_incidentsOpen and recent alert incidents with their type, current and baseline values, and the change.
get_incidentOne incident in full: its rule and scope, values, Kubeadapt's findings about the cause, and the timeline.
search, fetchTurn "checkout" or "the prod cluster" into the ids the other tools take, and open one record.

What the answer contains

  • Both periods. current_window and baseline_window, current_total_usd, baseline_total_usd, change_usd and change_pct.
  • Movers. Up to 10 rows by default (50 at most), each with current_usd, baseline_usd, change_usd, change_pct and a status: new (no cost in the baseline), gone (no cost now) or changed.
  • Incidents. The value and its unit: a cost spike is in US dollars per day, a new expensive workload in dollars per month, and a budget in dollars spent in the budget period with the share of the budget used. get_incident adds the findings about the cause, or says why there are none, and the timeline from detection to resolution.
  • Usage. Average, p95 and peak CPU and memory against what was requested, the busiest hour of the day in UTC, and the direction of the trend.
  • Provenance and notes. Both windows in UTC calendar days and the cost mode. If the periods straddle a change in how Kubeadapt allocated cost, a note says those days are not directly comparable.

Cost mode. Both periods use the same cost mode, fully loaded unless you ask for workload-only. In fully loaded cost, a workload's share of idle capacity can rise when other workloads shrink, even if the workload itself didn't change. Ask for workload-only cost to separate the two.

Follow-ups

plaintext
Get the rightsizing plan for the workload that grew most.
plaintext
Show its CPU use by hour of day over the last two weeks. When does it peak?
plaintext
Who does that workload talk to, and did its network cost change?
plaintext
Open this comparison in Kubeadapt.

Limits

  • What moved, not who moved it. Kubeadapt sees cost and usage, not your commits, releases or tickets. Match the movers against your own deployment history.
  • Top 100 rows per side. Each period reads its 100 most expensive rows. A row outside one side's top 100 is listed separately, with its other side unknown.
  • Periods up to 366 days. Usage history covers at most 60 days per question.
  • Incidents come from your alert rules. Muted and disabled rules open no incidents. Kubeadapt MCP can't acknowledge, snooze or resolve an incident; do that in Kubeadapt.
  • Read-only. Nothing in Kubeadapt or in your clusters changes.

Related