Tracking cloud costs

Bring cloud cost data into Cortex so teams can monitor spend without leaving the platform

Bring cloud spend into Cortex so infrastructure cost lives alongside the rest of your engineering health data (deployment frequency, reliability, scorecard compliance) instead of sitting in a separate FinOps tool that engineers never open.

This guide walks through surfacing actuals, budgets, and forecasts at the team level, displaying them on entity pages, and wiring cost into your scorecards. By the end, your engineering managers will be able to answer, How much is my team spending, and are we on track against budget?, without leaving Cortex.

Prerequisites

1. The Configure Eng Intelligence custom metrics permission to create and publish metric definitions.

2. An API key with the same permission if you plan to push data programmatically (most cloud cost setups do).

3. Cost data you can export on a schedule from your cost management platform (AWS Cost Explorer, Azure Cost Management, Databricks, New Relic, etc.), or a CQL-computable source already in Cortex.

Custom metrics or custom data?

Use custom metrics for anything that changes over time, e.g. monthly spend, budget targets, and forecasts. Cost dollars are a time series, so they belong in custom metrics. See Custom metrics to learn more.

Use custom data for slowly-changing tags like a cost-center or cost-attribution override. Refer to Custom data for more information.

Step 1: Modeling your cost metrics

Cloud cost is most actionable at the team level where a budget owner can actually do something about it. Attach your metrics to team-type entities rather than individual services, at least to start.

A complete picture has three dimensions. A typical setup uses one metric per provider, per dimension:

Actuals (what was spent):

• Total cloud cost

• AWS cost

• Azure cost

• Databricks cost

• New Relic cost

• AWS Marketplace cost

Budgets (planned spend targets):

• Budgeted AWS

• Budgeted Databricks

• Budgeted New Relic

Forecasts (projected spend for the period):

• Forecast AWS

• Forecast Databricks

• Forecast New Relic

You don't need every provider in every dimension. It's common for actuals to flow for more teams than budgets and forecasts, since budget planning is usually formalized for a smaller subset. Start with actuals everywhere, then layer in budgets and forecasts where the planning data exists.

Step 2: Creating custom metrics

Add custom metrics in Cortex via CQL or API. Refer to the table below for field definitions.

Field	Definition
Ingestion method	Choose API for cost data exported from an external platform (the common case), or CQL if the underlying numbers already exist in Cortex. If you choose CQL, Cortex evaluates the expression every 12 hours and the result must resolve to a number, or it fails validation.
Name	The name of the custom metric. This is how it appears in Eng Intelligence, e.g. AWS Cost.
Key	A unique identifier of letters, digits, and hyphens, e.g. aws-cost. Tip: Keep a consistent prefix scheme like cost-actual-aws, cost-budget-aws, cost-forecast-aws so the three dimensions group cleanly later.
Trend color indicator	Determine if an upward or downward trend is positive.
Draft	Toggle off once you've validated the data, to make it visible to everyone with Eng Intelligence access.

Step 3: Pushing your cost data

For externally-sourced cost data, post to each metric via the API on a regular cadence (a daily or monthly job, depending on how often your platform closes the books).

• Add points to a single entity, or bulk-add multiple points using createBulkCustomMetricData to load many teams at once.

• You can backfill up to two years, so load historical spend on first setup to get trends immediately rather than waiting months for them to accumulate.

• All API requests need an Authorization: Bearer <token> header.

A few operational notes:

• Cortex lags custom metric results until the end of the previous day, so today's posted data won't render until tomorrow.

• Bulk metric creation via the API is rate-limited. If you're loading dozens of teams, batch your requests and handle 429 responses with a retry-after delay rather than hammering the endpoint.

• Custom metric data is retained for 24 months.

Step 4: Surfacing cost on team pages with a plugin

Eng Intelligence and Data Explorer show your cost metrics out of the box, but a dedicated custom plugin gives budget owners a purpose-built view on their team page.

Build a plugin that displays:

• Cloud cost trends across providers

• Budget vs. actuals comparison

• A unified spend view across AWS, Azure, Databricks, and New Relic

Scope the plugin to team-type entities only, so it appears where cost is actionable and stays off individual service pages where it would just be noise. The plugin reads your metric data through the Cortex API, so it stays in sync with whatever cadence you're posting on.

Step 5: Tagging entities for cost attribution (custom data)

If you need to attribute or override how individual services and resources roll up to a cost center, use a custom data field rather than a metric (this is the slowly-changing-metadata case). A field like operational-cost-override applied across your catalog lets your cost platform (or your own CQL) map services back to the right team or product.

This is what makes accurate chargeback and showback possible: the metrics tell you how much, the custom data tells you whose.

Step 6: Putting cost to work in Scorecards and reports

Once cost is flowing, it stops being a dashboard and starts being a control:

• Scorecard rules - Flag teams whose actual spend exceeds forecast by more than a threshold, or whose spend has grown month-over-month beyond a set percentage. Cost becomes a standard you can drive, not just a number you observe. See Scorecard rule filters

• CQL reports - Build a tabular, cross-team cost comparison so leadership can rank spend without manually aggregating from a finance export. See Using CQL reports

• Service-level cost - Once team-level patterns are solid, extend attribution down to individual services using your cost-attribution custom data, so you can answer, Which service is driving this team's bill?

What you end up with

Cost data living where engineering decisions are made—closing the loop between the teams writing the code and the teams accountable for the bill—scoped to the level where someone can act on it, and tied into the same scorecards and reports that govern everything else in your catalog.