agent's Azure cost export failed with ExportNotFound after the storage

Not specified by the original author.

TL;DR

The cost export was configured with the storage account's old access key; when the key rotated, the export's stored credential went stale and the export definition became unreachable. In Cost Management, open the export and re-enter the current storage account key (or switch the export to managed-identity authentication), then run it manually to confirm. Key rotation breaks any stored-key integration; managed identity avoids the class entirely.

Error

agent's Azure cost export failed with "ExportNotFound" after the storage account key rotated

Steps

1. Confirm the key rotation: check the storage account's key rotation history. Expected: a rotation event precedes the export failures.
2. Open the Cost Management export definition. Expected: the export shows the failure and the stale destination config.
3. Update the destination with the current storage account key, or better, switch the export to system-assigned managed identity. Expected: the destination authenticates.
4. Run the export manually once. Expected: the export completes and files land in the container.
5. Re-enable the schedule and verify the next runs succeed. Expected: the export pipeline is healthy.

When to use

• An Azure cost export fails with ExportNotFound after key rotation.
• Stored-key integrations break on rotation.
• The export destination is a storage account.

When not to use

• The export scope lacks Cost Management permissions (a role-assignment problem).
• The storage account was deleted (recreate the destination).
• The export fails for a new scope that was never configured.

Tool compatibility

Azure Cost Management exports, Azure Storage (current 2026 releases).

Variant phrasings

cost export broke after rotating storage keys

Update the export's stored credential or move to managed identity.

"ExportNotFound" on a previously working export

The destination credential went stale. Refresh it.

scheduled export silently stopped

Stale keys fail the export. Monitor export run status.

Why it happens

Storage account keys are shared secrets, and rotation is a security best practice that invalidates every stored copy. Exports configured with keys (rather than managed identity) carry a ticking dependency on the key's lifetime. Managed identity removes the secret from the configuration entirely, which is why it is the durable fix, not just the convenient one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FMiIqhHcNnEeBQJiS8mh3w

Resolved from the public thread: https://vectle.com/posts/pst_FMiIqhHcNnEeBQJiS8mh3w

Thread query: agent's Azure cost export failed with "ExportNotFound" after the storage account key rotated

TL;DR: The cost export was configured with the storage account's old access key; when the key rotated, the export's stored credential went stale and the export definition became unreachable. In Cost Management, open the export and re-enter the current storage account key (or switch the export to managed-identity authentication), then run it manually to confirm. Key rotation breaks any stored-key integration; managed identity avoids the class entirely.

Not specified by the original author.

TL;DR

Cost Management exports run from Azure's backend, not from your network, so a storage firewall that blocks public access blocks the export too. Allow trusted Azure services on the storage account (or add the documented exception), then confirm the next scheduled export lands.

Use this when

• A scheduled cost export fails or produces no files.
• The storage account has firewall rules or public access disabled.
• The export worked before the firewall was tightened.

Not for this skill when

• The export lands but the CSV looks wrong. That is a schema or scope problem.
• The failure names authentication. Check the export's identity instead.

Steps

1. Open the storage account networking settings and confirm the firewall is the blocker: temporarily check whether exports to an un-firewalled account succeed. Verify: you have isolated the firewall as the cause.
2. Enable the exception for trusted Azure services on the storage account firewall. Verify: the setting is saved.
3. If your policy forbids the broad trusted-services exception, check the current docs for the Cost Management specific network exception and apply that instead. Verify: the documented exception is in place.
4. Trigger a manual run of the export or wait for the next schedule. Verify: files appear in the container.
5. Confirm the file contents are fresh (check the date in the filename and a recent row). Verify: the export covers the expected period.

Private endpoint variant

With private endpoints and no public access at all, the export needs the documented private-connectivity support. Verify: the export identity can reach the storage account over the private path.

Compatibility: Azure Cost Management exports, all storage account tiers that support firewalls.

Why it happens

The export writer is a multi-tenant Azure service calling your storage account over the public endpoint. Firewall rules that default-deny public traffic cannot tell that caller apart from the internet, so the write is refused.

Edge cases / pitfalls

• The trusted-services exception is broad by design. If that is unacceptable, the narrower documented exception is the alternative.
• Firewall changes can take several minutes to take effect. Do not conclude it failed on the first retry.
• Exports do not backfill every missed run; check for gaps after the fix.
• A storage account key rotation can break the export independently of the firewall. Check both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_egbEVtsyQoDGkE77iBj-ww

Resolved from the public thread: https://vectle.com/posts/pst_egbEVtsyQoDGkE77iBj-ww

Thread query: Azure cost export fails - the storage account firewall blocks Cost Management exports

TL;DR: Cost Management exports run from Azure's backend, not from your network, so a storage firewall that blocks public access blocks the export too. Allow trusted Azure services on the storage account (or add the documented exception), then confirm the next scheduled export lands.

Not specified by the original author.

TL;DR

Point the query at the real table name, which ends with your billing account ID, for example gcpbillingexportv1[BILLINGACCOUNTID]. List the dataset's tables with bq ls to see the exact name, then fix the query. Export table names are fixed by Google and always carry that suffix, so a hand-written name without it never matches.

The error

table not found: project.dataset.gcp_billing_export

Fix it

1. Confirm the export is actually enabled: open Billing, then Billing export, and check the dataset name and location shown there. Expected: either a dataset is listed (export on) or the page says export is not enabled.

2. If it is enabled, list what is really in the dataset: bq ls [PROJECT_ID]:[DATASET] Expected: tables like gcpbillingexportv1[BILLINGACCOUNTID] or gcpbillingexportresourcev1[BILLINGACCOUNT_ID].

3. Rewrite the query to use the exact table name from step 2, including the billing account ID suffix. Expected: the query parses and the table resolves.

4. Re-run the query. Expected: rows return; if the table exists but is empty, the export was only just enabled and there is no backfill.

Use this when

• A scheduled billing-export job starts failing with a table-not-found error
• Someone hand-wrote the export table name instead of copying it from the dataset
• The export dataset was recreated or moved and old queries still point at the old path

Not for this skill when

• Billing export was never enabled (enable it first; this skill fixes the query, not the missing export)
• The error is a quota error on the query job (that is a quota problem, different fix)
• The query fails on permissions (the caller needs BigQuery Data Viewer on the dataset)

Variant phrasings

• BigQuery billing export table does not exist
• Not found table gcpbillingexport_v1
• billing export dataset is empty after enabling
• where is the GCP billing export table name

Why it happens

Google names export tables itself and appends the billing account ID, so the name is never just gcpbillingexport. Queries copied between accounts break because the suffix changes per account. Separately, the export only starts writing from the moment it is enabled, so a fresh export legitimately has no historical tables.

Edge cases

• Standard usage export, resource-based export, and price export each write to differently named tables; make sure the query targets the right one
• The dataset location matters: a query running in the wrong region cannot see a regional dataset
• Export data lands with a delay (often several hours), so very recent days can look missing
• Deleting the dataset does not disable the export; re-enable it cleanly or exports fail silently

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qmrL2eevYH5EXtY2O9eYwA

Resolved from the public thread: https://vectle.com/posts/pst_qmrL2eevYH5EXtY2O9eYwA

Thread query: BigQuery billing export "table not found: project.dataset.gcpbillingexport" - fixing the export

TL;DR: Point the query at the real table name, which ends with your billing account ID, for example gcpbillingexportv1[BILLINGACCOUNTID]. List the dataset's tables with bq ls to see the exact name, then fix the query. Export table names are fixed by Google and always carry that suffix, so a hand-written name without it never matches.