You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
FinOps Hub upgraded from v13 to v14- two months data is missing in dashboard #2206
I think this could be related to data retention, by default it's 13 months. If you had for example configured 15 months with v13, and used default configuration for v14 this would be changed back to 13. Upgrade of FinOps should not delete any data.
@description('Optional. Number of months of data to retain in the ingestion container. Default: 13.')
param ingestionRetentionInMonths int = 13
@description('Optional. Number of months of data to retain in the Data Explorer *_final_v* tables. Default: 13.')
param dataExplorerFinalRetentionInMonths int = 13
changed the title [-]Finops Hub upgraded from v13 to v14- two months data is missing in dashboard[/-][+]FinOps Hub upgraded from v13 to v14- two months data is missing in dashboard[/+]on Jul 22, 2026
🤖 [AI] Thanks for confirming it's the oldest two months that are missing — that detail pinpoints the mechanism.
ingestionRetentionInMonths / finalRetentionInMonths are Bicep parameters that default to 13 if not explicitly passed on a given deploy. Copy-FileToAzureBlob.ps1 then unconditionally overwrote settings.json's stored retention with whatever value it received — with no check for whether that value was actually lower than what was already configured. The Data Factory purge pipeline reads that value directly and ages out data older than the cutoff, oldest first.
So if your v13→v14 redeploy call didn't explicitly re-specify a retention value above 13 months (for example, if it had been customized higher previously, or the v14 portal UI reshuffle — retention fields are now only shown when Data Explorer mode is explicitly selected — caused the field to be skipped), the redeploy would have silently reset settings.json back to the 13-month default, and the next pipeline run would have purged your two oldest months.
We've opened #2288 to fix this: retention can now only grow on redeploy, never shrink, so this class of silent data loss shouldn't be possible going forward regardless of how a redeploy is triggered.
This doesn't recover the two months you already lost, unfortunately — once purged, that data isn't recoverable from the pipeline. If you still have the original Cost Management export data or raw exports retained elsewhere for that period, re-ingesting from there would be the only way to backfill it.
Activity
microsoft-github-policy-service commentedon Jul 8, 2026
Thank you for submitting this issue! We try to respond within 3 business days. In the meantime:
Vikesh1981 commentedon Jul 8, 2026
FinOps hub version: v14
Billing account type: EA (Enterprise Agreement)
Power BI report type: Storage-based / ADX (Azure Data Explorer)
Cost Management export: Dashboard
fajterini commentedon Jul 13, 2026
Latest 2 months or oldest 2 months of data are missing ?
Vikesh1981 commentedon Jul 13, 2026
fajterini commentedon Jul 13, 2026
I think this could be related to data retention, by default it's 13 months. If you had for example configured 15 months with v13, and used default configuration for v14 this would be changed back to 13. Upgrade of FinOps should not delete any data.
You can see this in main.bicep file >> https://github.com/microsoft/finops-toolkit/blob/dev/src/templates/finops-hub/main.bicep
Vikesh1981 commentedon Jul 13, 2026
[-]Finops Hub upgraded from v13 to v14- two months data is missing in dashboard[/-][+]FinOps Hub upgraded from v13 to v14- two months data is missing in dashboard[/+]flanakin commentedon Aug 26, 2026
🤖 [AI] Thanks for confirming it's the oldest two months that are missing — that detail pinpoints the mechanism.
ingestionRetentionInMonths/finalRetentionInMonthsare Bicep parameters that default to 13 if not explicitly passed on a given deploy.Copy-FileToAzureBlob.ps1then unconditionally overwrotesettings.json's stored retention with whatever value it received — with no check for whether that value was actually lower than what was already configured. The Data Factory purge pipeline reads that value directly and ages out data older than the cutoff, oldest first.So if your v13→v14 redeploy call didn't explicitly re-specify a retention value above 13 months (for example, if it had been customized higher previously, or the v14 portal UI reshuffle — retention fields are now only shown when Data Explorer mode is explicitly selected — caused the field to be skipped), the redeploy would have silently reset
settings.jsonback to the 13-month default, and the next pipeline run would have purged your two oldest months.We've opened #2288 to fix this: retention can now only grow on redeploy, never shrink, so this class of silent data loss shouldn't be possible going forward regardless of how a redeploy is triggered.
This doesn't recover the two months you already lost, unfortunately — once purged, that data isn't recoverable from the pipeline. If you still have the original Cost Management export data or raw exports retained elsewhere for that period, re-ingesting from there would be the only way to backfill it.
fix(hubs): anchor regression guard regex in HubsRetentionGuard.Tests.ps1
fix(hubs): keep retention on redeploy and upgrade unless specified