October release: meet Costory Scouts

Every alert and report answers the same questions, then raises new ones: why did it spike, which team, what changed? MCP helps, but it needs you at the keyboard. Costory already holds your cost data and your business and technical metrics. What it was missing was memory and orchestration.

Scouts add both. Assign a Scout to your reports and alerts. It reads each one, prepares the follow-up questions you would likely ask, and answers them directly in Slack, Teams or email.

Shape it to your needs. Talk to a Scout in Slack or through MCP to adjust its tone, choose what it shows you, or schedule recurring work. You can now talk to Costory from Slack: reinstall the app and then use @costory to ask any cost questions.

It learns from you. When a Scout finishes an investigation, it saves the result in a memory or creates events. Reply in Slack and tag @costory to refine the description or add missing context.

Scouts are free during Beta.

Customize alerts with reports

You can now build any alert’s content using reports: add a graph, a breakdown, whatever helps you understand it. Anything you add is also read by your Scout, so its explanation reflects exactly what you see.

Enrichments (Beta): map your catalog onto the bill

Virtual dimensions are still the quickest way to allocate costs when tagging is patchy. But some of you have outgrown long rule lists. When two rules match the same row, their order decides the result, and explaining why a cost landed in a bucket takes real time. Many of you also already know who owns what, and keep it in Backstage, a CMDB or a spreadsheet.

Enrichments sit between virtual tags and full tagging. You tag one stable key on your resources, such as a component. A dated mapping then turns that key into team, cost centre and business capability.

• One key in, several columns out. One file can hold thousands of keys. Generate it from your catalog with a script, keep it in git, and publish it through the API or the Costory Terraform provider.

• Reorgs don’t rewrite the past. Entries can carry dates, and every published change is backfilled over your full billing history. When a team is renamed this month, last quarter’s numbers stay the same.

• Usage-based splits for shared resources. Split a shared database each day based on usage metrics. The split row stays one row and shares must add up to 1, so totals still match the invoice.

name: component_ownership
description: Generated from the service catalog
keyField: component   # the column your component label lands in
#...
targetColumns:
  - name: team
    mode: replace
  - name: cost_center
    mode: replace
  - name: business_capability
    mode: replace
entries:
  # a reorg: past costs keep the old owner
  - key: checkout-api
    when: { start: "2025-01-01", end: "2026-03-31" }
    then:
      team: Payments
      cost_center: CC-410
      business_capability: Checkout
  - key: checkout-api
    when: { start: "2026-04-01" }
    then:
      team: Commerce Platform
      cost_center: CC-520
      business_capability: Checkout
  # a shared database: each team pays its share of daily query time
  - key: orders-postgres
    then:
      metric:
        integrationId: datadog
        query: sum:postgresql.queries.time{db:orders} by {team,cost_center}
      propagates

name: component_ownership
description: Generated from the service catalog
keyField: component   # the column your component label lands in
#...
targetColumns:
  - name: team
    mode: replace
  - name: cost_center
    mode: replace
  - name: business_capability
    mode: replace
entries:
  # a reorg: past costs keep the old owner
  - key: checkout-api
    when: { start: "2025-01-01", end: "2026-03-31" }
    then:
      team: Payments
      cost_center: CC-410
      business_capability: Checkout
  - key: checkout-api
    when: { start: "2026-04-01" }
    then:
      team: Commerce Platform
      cost_center: CC-520
      business_capability: Checkout
  # a shared database: each team pays its share of daily query time
  - key: orders-postgres
    then:
      metric:
        integrationId: datadog
        query: sum:postgresql.queries.time{db:orders} by {team,cost_center}
      propagates

name: component_ownership
description: Generated from the service catalog
keyField: component   # the column your component label lands in
#...
targetColumns:
  - name: team
    mode: replace
  - name: cost_center
    mode: replace
  - name: business_capability
    mode: replace
entries:
  # a reorg: past costs keep the old owner
  - key: checkout-api
    when: { start: "2025-01-01", end: "2026-03-31" }
    then:
      team: Payments
      cost_center: CC-410
      business_capability: Checkout
  - key: checkout-api
    when: { start: "2026-04-01" }
    then:
      team: Commerce Platform
      cost_center: CC-520
      business_capability: Checkout
  # a shared database: each team pays its share of daily query time
  - key: orders-postgres
    then:
      metric:
        integrationId: datadog
        query: sum:postgresql.queries.time{db:orders} by {team,cost_center}
      propagates

We designed this with two customers who already tagged one component key and wanted their catalog to stay the source of truth. If that sounds like your setup, the enrichments docs cover the file format, testing and Terraform publishing. The full story is on the blog: Why we built enrichments.

Understand and optimize your BigQuery costs

Data ingestion is our biggest cost, so we’ve wanted deep BigQuery visibility inside Costory for months. Selling software at €250 a month forces us to be careful with FinOps. 😅

You can now ingest the information schema of your BigQuery jobs and storage directly inside Costory. This lets you:

1. Fill the tagging gap. Enrich each job with the user who triggered it, the destination table, referenced tables and more.

2. See compute metrics, duration and cost metrics in a single tool. Compare autoscaling slots against on-demand to optimize your spend and reduce your bill.

Enable it here: BigQuery jobs setup.

Take your billing data anywhere

Every company already has a dashboarding tool: Looker, Metabase, Dust. You can now export your homogenized billing data back to your analytical engine:

• BigQuery through table sharing (EU region only for now).

• Any Apache Iceberg reader, such as Snowflake, DuckDB, ClickHouse or Polars (private beta, contact us).

The table is exported as is, in Iceberg with consolidated, compressed Parquet files. During the private beta, we provide it as a GCS bucket in europe-west1 where we grant you IAM read access. Network egress costs fall under fair use.

What’s next: LLM cost enrichment

We plan to work in November and December on LLM Cost Enrichment. Unfortunately providers don’t seem to give us much depth on LLM visibility: today the most viable option is to use a gateway to centralize calls and enforce a tagging policy. What is your experience? What do you expect from us for this new cost category? Here is our take based on our experience migrating to OpenRouter: OpenRouter cost visibility.

Contact us

A few small improvements you might not have noticed

1. For accounts with hourly visibility you can now change the timezone of the app to use your local tz instead of UTC.

2. On dashboards, you can now apply custom pivots on table widgets.

1. You can switch the color palette of your charts easily.

2. and many more…