Skip to main content
Most integrations bring cost data into CostGraph. Metronome is the opposite direction: CostGraph reports each of your customers’ attributed cloud spend to your Metronome account every night as usage events, and Metronome turns them into invoices. You resell or charge back cloud infrastructure; CostGraph decides who spent what, Metronome bills them for it.

​
How it fits together

  1. A virtual tag decides which customer each charge belongs to. You write the rules; every value the tag produces is a Metronome customer id.
  2. A meter binds that tag key to one event type in your Metronome account. Each night CostGraph reports every customer’s attributed spend for each settled day under that event type.
  3. Metronome prices and invoices. A billable metric filters those events by event type and aggregates them, and the rate attached to it bills your customers for exactly the spend CostGraph attributed to them.
Spend is reported in integer cents. Price per cent, or divide by 100 in the metric, because Metronome does not know what unit the events carry and nothing on its side will catch a rate set as if the values were dollars.

​
Connect

1

Create an API token

In Metronome, open Settings -> API tokens and copy a token.
2

Connect in CostGraph

Open Integrations, choose Metronome, and paste the token. CostGraph verifies it against Metronome before saving anything, and stores it encrypted.
3

Bind a billable metric

Bind a virtual tag key to one of your billable metrics. CostGraph lists a metric once per event type in its event type filter, and reports events under that event type. A metric with no event type filter matches every event and cannot be targeted, so it is not offered.

​
Choose who gets billed

Create a virtual tag key named with a metronome_ prefix, such as metronome_customer. The prefix is required: it marks the key as billing-bound, and only prefixed keys can be bound to a meter. The value a rule assigns is the Metronome customer id the spend is reported under: Any field works as the match: a linked account per customer, a resource name prefix, a project, or an existing tag. See Virtual tags for the rule builder and how overlapping rules resolve. Spend the tag does not match is never reported.
Metronome accepts events for ids it does not recognise and leaves them unmatched rather than rejecting them outright, so a mistyped tag value can look like a successful report while billing nobody. Check the tag’s values against your Metronome customers before binding it to a metric, and reconcile the first few invoices.
Because a bound tag key drives invoices, CostGraph protects days that were already reported: rules on that key cannot be reordered, and new or edited rules must start from a date that has not been reported yet. Close an old rule with an end date instead of editing it in place.

​
What lands in Metronome

Each customer-day is one usage event. Its transaction_id is derived from the day and the totals, so a retried run is treated as a duplicate and ignored rather than counted twice. Its properties carry: Set the metric’s aggregation to sum over the value property, so that corrections - which are sent as the difference, and can be negative - settle to the right total.
Cloud providers restate recent spend, so CostGraph holds each day for two days before reporting it, then keeps reconciling the last 35 days. Metronome ignores a transaction id it has already seen for 34 days. A correction carries totals that differ from the last one sent, so its transaction id differs too and it is never mistaken for a replay.

​
Day to day

  • The nightly run reports only what changed, so an unchanged day sends nothing.
  • A day is held back rather than reported wrong when its spend mixes currencies, or a quantity meter meets an unexpected unit. Each held day is recorded with its reason.
  • Deactivating a meter stops reporting but keeps its history, so reactivating resumes from what was already sent instead of double-billing the window.

​
Next steps

Virtual tags

Write the rules that decide which customer each charge belongs to.