Cost
Cost shows what every cluster, application, model and add-on costs, one closed hour at a time: what it reserved next to what it used, priced from your cloud's published prices or your own rates. It is measured inside your cluster by the Cost Visibility add-on, and every total says how much of the window it actually measured: a missing hour is never counted as zero. For live use and model latency, see Metrics.
When you need it
- Which app costs what. Spend per application, namespace or node group, adding up to the cluster total.
- Where money is idle. Capacity you pay for that no workload reserved, and workloads that reserve far more than they use.
- Reconciling with your bill. What is in the total, what is left out, and why.
Before you start
- A cluster with a connected Astro Agent and the Cost Visibility add-on. On AWS and Azure, spend is priced from the cloud's published prices with no setup; anywhere else, add a price sheet, or cost is measured but reads Not priced.
In the console
-
Open a cluster from the cluster list and select Cost. Cost analysis opens on Last 24 hours; pick Last 7 days or Last 30 days. The badge beside them is the window's coverage.
-
Read the cards: Observed spend (the cluster total), Report coverage (measured hours out of expected), Request utilization (used out of allocated) and Last report.
-
Under Cost allocation, switch between Namespaces, Applications and Node groups, search, and sort, for example by Lowest request utilization to find over-reserved workloads. The rows plus the Idle, Cluster infrastructure and Outside applications rows add up to Observed spend.
Open zoom view -
Open an application or model and select Cost for its own spend and Share of cluster.
Open zoom view -
An add-on has its own Cost tab: open it from the cluster's Add-ons tab.
You should see
The first figures after the first full hour closes, then one more each hour. Coverage at 100% once the add-on has run for the whole window; below that, the note says how many hours are missing and that they are not counted as $0.
How to read the numbers
- Allocated and used. A workload is allocated the larger of what it requests and what it uses, each hour. A Pod that requests four cores and idles holds four cores the scheduler can't give to anything else. Every view shows allocated next to used: a large gap marks a workload to look at, not a safe new request. Check its peaks, autoscaling and limits before you change it.
- Missing is never zero. An hour with no report is missing; an hour reported as unmeasurable is a gap. Neither is counted as $0 or plotted as zero. Check coverage before you act on a number: a cheap-looking day may be a partly measured one.
- Utilization can pass 100%. A workload using more than it reserved is shown above 100%, not capped.
- No requests set is shown as none set, not 0% or 100%: a ratio against zero is not a measurement.
- CPU and memory are separate, because each is sized on its own.
What the total includes
Each closed UTC hour records CPU, memory, GPU and persistent-volume allocation, network bytes, and what was used. Hours add up to the window; the hour in progress is never included.
The total also includes what AstroPulse provisioned around the cluster, each as its own row:
- Idle capacity: node capacity you pay for that no workload was allocated.
- Unmounted storage: volumes no Pod mounted during the hour.
- Cluster management: the managed control plane fee, on EKS, or on any cluster whose price sheet sets a rate for it.
- NAT gateways and Public IPv4 addresses: the NAT gateways AstroPulse created with an EKS cluster's VPC, and their addresses.
- Load balancers: the load balancer in front of the Kubernetes API of a self-hosted cluster on AWS.
Left out: data transfer and NAT data processing (measured, not priced), public addresses of load balancers and public nodes, the EKS Auto Mode management fee, volumes kept after a cluster is deleted, and support, licences, taxes, credits and discounts. Published prices are list prices, before any Savings Plan, reservation or negotiated discount; a price sheet with your real rates comes closer to your invoice. Cost is per closed hour, not per request, token or customer.
How cost is allocated
- Namespaces (the default): a row per Kubernetes namespace.
- Applications: a row per application or add-on, by the label AstroPulse puts on what it deploys.
- Node groups: a row per node pool, by the node each Pod ran on; nodes with no pool label are
default.
In every grouping, the rows plus the spend no row owns equal the cluster total: Idle, Cluster infrastructure, and (by application) Outside applications, the Pods AstroPulse did not deploy, such as kube-system. Idle capacity is usually the most actionable number: persistent idle means the cluster is larger than what runs on it.
Where prices come from
- List price (the default on AWS and Azure): your cloud's published on-demand and Spot prices for the cluster's region.
- Your rates: the core-hour, GB-hour, GPU-hour and cluster-management rates in your price sheet, on any cluster.
- Not priced: usage is measured but has no price; the notice under the cards says why.
Each hour is priced once, when it is reported. Changing pricing never rewrites past hours, so one window can mix sources; totals are kept per currency and source, never added across them, and no currency is converted. A cluster on Google Cloud, a registered cluster outside AWS and Azure, or a local one reads Not priced until it has a price sheet. Setup: Pricing modes and Price sheets.
How long history is kept
Cost history is kept 1 day on Developer and 395 days on Enterprise (a default each organization can change).
This is how long AstroPulse keeps priced hours, and it is the history you read. It is separate from the retention of the metrics backend in your cluster (7 days by default), which only decides how many missed hours the agent can still send after a disconnect, and which costs you a volume: Run Cost Visibility in production.
Any read covers at most the last 45 days. Deleting a cluster, or unregistering one, removes its whole cost history at once, on every plan, and re-creating a cluster with the same name does not bring it back. Export first:
astroctl infra k8s cost allocation my-cluster --group-by Application --window 30d -o json > my-cluster-cost.json
What leaves your cluster
The agent measures cost inside the cluster and sends AstroPulse per-application totals: not your Pod names, images, logs or environment. A cluster that is briefly disconnected loses nothing: the agent holds finished hours (up to 168) and sends them when it reconnects.
Other ways in
- Nova: ask, for example, "which workloads on my-cluster reserve far more CPU than they use?"
- API: the cost calls in the API reference.
With astroctl
astroctl application cost checkout --window 24h
astroctl infra k8s cost summary my-cluster --window 24h
astroctl infra k8s cost allocation my-cluster --group-by Application --sort-by Efficiency --sort-order Ascending
astroctl infra k8s addons cost my-cluster cost-visibility --window 24h
Windows are whole hours from 1h to 45d. Every command takes -o json.
If it's refused
cost reporting check says which hour it is waiting for.astroctl infra k8s cost trend <cluster> --window 7d --interval 1h, then read the add-on's health: astroctl infra k8s addons get <cluster> cost-visibility. Hours older than the agent's 168-hour buffer, or than 30 days, stay missing.pricingRoleArn: Pricing modes.--window is outside what the cost API accepts.1h to 45d.