AppStatus Documentation Hub for Production Operations

Docs > Platform Observability > Getting Started with Cloud Cost

Getting Started with Cloud Cost

Overview

This guide introduces AppStatus Cloud Cost and covers:

  • Spend broken down by service, cluster and workload
  • Kubernetes cost derived from real resource consumption
  • Cost shown next to the traffic it serves
  • Threshold alerting on rate of change
  • Read-only access to connected cloud accounts

What is Cloud Cost in AppStatus?

Cloud Cost brings spend into the same place as your performance data. Instead of a bill in one tool and latency in another, you see what a workload costs beside how much traffic it actually serves.

That pairing changes which questions you can answer. Total spend growing alongside traffic is not waste; spend growing while traffic is flat is a configuration change, and the least-used workload is more often the problem than the most expensive one.

Key capabilities:

  • Cost attribution by service, cluster and workload
  • Kubernetes cost derived from actual consumption
  • Cost-per-request alongside absolute spend
  • Change-rate thresholds rather than monthly-total alerts
  • Read-only connections — nothing here needs write access

What you will see

What the cost breakdown looks like

app.appstatus.ioSample data
WorkloadMonthlyChangeRequestsCost / 1k req
search-service$1,840+4%82M$0.022
checkout-api$960+2%36M$0.027
report-export$1,210+180%0.4M$3.025
notification-svc$140−6%2.5M$0.056

Scroll the table sideways to see every column.

Row three is the point of this view: high spend, almost no traffic, and a jump nothing else explains.

Troubleshooting

Cost data is missing for an account

Confirm the account is connected in Cloud Integrations and that billing access was granted. Providers publish billing data on their own schedule, so the newest days can lag by a little.

Attribution is coarse — everything lands in one bucket

Attribution follows your tags. Workloads without consistent tags cannot be separated, so tag first and the breakdown sharpens immediately.

Spend jumped with no deploy

Look for a configuration change rather than a code one — a scaling policy, a retention setting, or a new region. Flat traffic with rising spend is nearly always configuration.

Operational Guidance

  • Cost per request is more useful than total spend — growth is not the same as waste.
  • The most expensive workload is not always the problem; the least-used one usually is.
  • A spend jump with flat traffic means a config change, not demand.

Step-by-Step Setup

Cost data follows your cloud connections, so start there. The setup that gives this page its value is tagging — attribution can only be as sharp as the tags your workloads carry.

Before you start

  • Cloud accounts connected in Cloud Integrations
  • Billing read access granted on those accounts
  1. 1

    Connect your cloud accounts

    Connect each account in Cloud Integrations with read-only access. Nothing about cost collection requires permission to change anything.

    WhereCloud Integrations → Add connection
  2. 2

    Confirm cost data arrives

    Open Cloud Cost and confirm spend appears broken down by service. Providers publish billing data on their own schedule, so the most recent days can lag.

    WhereCloud Cost → Overview
  3. 3

    Tag workloads consistently

    Attribution follows your tags. Workloads without consistent tags collapse into one bucket, so tag first — the breakdown sharpens immediately afterwards.

    WhereYour deployment manifests
    Tip

    This is the difference between "cloud costs $4,000" and knowing which workload to fix.

  4. 4

    Read cost against traffic

    Open the breakdown and compare each workload against the requests it serves. The most expensive workload is not usually the problem; the least-used one often is.

    WhereCloud Cost → Breakdown
  5. 5

    Alert on change, not total

    Set a threshold on rate of change rather than the monthly total. Growth that tracks traffic is not waste; a jump with flat traffic is a configuration change worth catching the same week.

    WhereCloud Cost → Thresholds

Configuration Options

Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.

Attribution and alerting

FieldOptionsWhat it doesRecommended
Cloud accountRead-only connectionSource of billing data.Read-only. Nothing here needs write access.
AttributionTags / labelsMaps cost onto workloads.Tag consistently or the breakdown stays coarse.
Spend thresholdAbsolute / rateWhen a change is flagged.Rate of change. A monthly total alert always arrives too late.

Feature Reference

Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.

FeatureWhere in appDescription
Cost breakdownCloud Cost → BreakdownSpend by service, cluster and workload.
Kubernetes costCloud Cost → ClustersDerived from real resource consumption.
Cost per requestCloud Cost → BreakdownSpend read against the traffic it serves.
Change alertsAlertsCatch a jump the week it happens.

Next Steps

Continue building your monitoring stack: