FinOps / Cloud Data Engineering

Recovering a production cloud-billing pipeline after upstream schema evolution

A daily cloud-cost ingestion pipeline began failing after a provider export introduced an additional nested field. The target schema was safely evolved, failed periods were reprocessed, and source-to-target coverage was validated.

FinOpsBigQueryCloud BillingData EngineeringProduction Recovery
Evidence standard. This case study describes engineering work and platform capabilities that were actually implemented. Customer identities and internal system names are intentionally omitted.

The problem

A production billing ingestion job that had been operating successfully began failing when the upstream cloud billing export changed the shape of a nested consumption-model structure. The source now contained an additional field that the target table did not yet accept.

Engineering response

  • Inspected source and target schemas rather than discarding the new provider field.
  • Extended the target nested structure to preserve the exported data.
  • Re-ran the affected ingestion period after the schema change.
  • Validated source partitions and target coverage to avoid silent gaps or duplicate recovery data.
Schema-awareProvider evolution handled without flattening data.
RecoverableFailed periods could be reprocessed.
ValidatedCoverage checked after recovery.

What Core generalises

The reusable pattern is authoritative discovery, schema-aware ingestion, recoverable processing and evidence that a repaired pipeline contains the expected data.

Have a similar problem?

We can review the architecture, evidence and operating constraints before proposing a pilot or engineering engagement.

Book a Technical Discovery