View usage metrics report

You've actually spotted a real contradiction in the docs, and clearing it up answers all of this: the usage metrics report is deliberately hidden.

Where it lives: it's created in the current workspace — the one containing the source report you ran it on. So your instinct is right, it's not somewhere else.

Why you can't find it: by design, usage metrics reports don't appear in Recent, Workspaces, Favorites, or any content list, and can't be added to an app (that's straight from the doc). So there's no browsable "Usage Metrics Report" item to look for — that's expected, not a bug.

The name, and the thing you can actually act on: what gets provisioned is a single semantic model per workspace called "Report Usage Metrics Model". That's the engine behind every usage metrics report in that workspace. The report is hidden; the model is the artifact you delete and recreate.

So the GCC delete/recreate, in practice: the doc says "delete the usage metrics report", but since the report itself is hidden, what you're really deleting is the "Report Usage Metrics Model" semantic model in that workspace. Remove that model, then open your report and choose View usage metrics report again — that regenerates the model with current data. That's almost certainly your fix for the data ending 12/8/2025: the model got stuck and stopped refreshing, and a rebuild is the documented GCC remedy. (If you don't see the model in the workspace's default view, switch the content view to show all item types / semantic models.)

Two prerequisites the doc calls out that catch people:

It can take up to 24 hours for data to update after (re)creation.

You have to view the content from within that workspace at least once, or the app-view data never gets correlated into the report. So after recreating, open the source report from the workspace itself once to unblock processing.

On the 30 days and whether it's configurable: the documented window is 90 days, and it's fixed — not a setting you can change. If GCC is showing only 30, that's a GCC-specific difference (GCC often trails commercial), but either way you can't extend it.

And the bigger-picture answer, since your real need is reliable recent usage: I wouldn't lean on the built-in usage metrics report for ongoing monitoring, especially in GCC where it's clearly flaky here. For dependable, longer-retention usage data, pull the tenant Activity Events (Admin portal audit/activity log, or Get-PowerBIActivityEvent / the Admin REST API) into your own Lakehouse or model. That gives you refreshable, retained usage history you control, instead of a hidden 90-day artifact that can silently stop.