Dataflow Gen 1 refresh history missing

Hi PowerUp2000​,

I would try to separate “the refresh history UI is missing entries” from “the refreshes never actually started”.

Since the missing period is still recent, there are two places I would check before assuming the dataflows did not run.

First, Power BI exposes a Get Dataflow Transactions API for Gen1 dataflows:

GET /v1.0/myorg/groups/{groupId}/dataflows/{dataflowId}/transactions

I would check one of the affected dataflows there and see whether transactions exist for 29 July through 6 August even though they are absent from the refresh-history UI.

The second place is the Power BI activity log. Microsoft documents the RequestDataflowRefresh activity as being generated when a dataflow refresh starts, including scheduled refreshes. The activity log keeps up to four weeks of history, so that date range should still be available.

That gives you a useful distinction:

• transaction/activity exists, but refresh history is missing: likely a history/display/telemetry issue
• no transaction and no RequestDataflowRefresh activity: much stronger evidence that the scheduled refresh never started

The lack of failure emails does not necessarily prove the refresh succeeded, because if the scheduled refresh was never initiated there may not have been a failed refresh execution to notify you about.

I would also verify that the refresh schedule itself remained enabled throughout that period, just to rule out the schedule being disabled or altered during the incident.

If both the REST transactions and activity log are blank for the same week across multiple Gen1 dataflows, I would open a Microsoft Support case with a couple of affected dataflow IDs and that exact date range. That would be much stronger evidence than the missing UI history alone.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi PowerUp2000 

Thanks for sharing the details.

The recent Gen1 Dataflows service incident was expected to affect refreshes during the outage window only. A week-long gap in the refresh history across multiple Gen1 Dataflows is not expected behavior.

If the refreshes did not occur, or if the refresh history is missing unexpectedly across your tenant, we'd recommend opening aMicrosoft Fabric Support and Status | Microsoft Fabric  so the service team can investigate backend logs and determine whether this is related to the recent incident or a separate issue.

Hi PowerUp2000 

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

PowerUp2000 Your two possibilities are separable without waiting on a support case, and I would do it this week rather than next, because the thing that answers it has a 28 day window and your gap starts on 29 July.

The audit log and the refresh history are different stores. So if a refresh actually started between 29 July and 6 August, there is a record of it that has nothing to do with the dataflow's own history pane being empty. The operation you want is RequestDataflowRefresh, documented as "A dataflow refresh starts. The refresh can be scheduled or triggered manually from the portal or an API", so scheduled runs are in scope.

Be precise about what that proves, because it is worth knowing before you go looking. It records that a refresh started, not that it finished. Present for those days means the schedules were firing and your question becomes what happened to the history. Absent across nine days and across every dataflow in the tenant means nothing was starting, and the question becomes why the schedules stopped, which is a different investigation and a much more alarming one.

A Fabric administrator can pull it from the Microsoft Purview portal under Audit, or from the activity events API, which is quicker for a date range like yours. The API constraint is the reason for the urgency: "StartDateTime and EndDateTime must be in the same UTC day, within the last 28 days". Today is the 11th, so 29 July is thirteen days back and comfortably inside it. Around the 26th it drops out. You need Tenant.Read.All and it is one call per UTC day, so your gap is about nine calls.

While you are in there, SetScheduledRefreshOnDataflow is also an audited operation. If somebody changed a schedule in that window, that shows up too, and it would explain a tenant-wide gap far better than a service incident would.

On the missing failure notifications, I would not treat that as evidence yet, in either direction. Check whether the additional recipients box was actually populated on the dataflows in question before reading the silence as data, because across a whole tenant it is unlikely to have been set on all of them. And a refresh that never started cannot fail, so silence is perfectly consistent with your option b anyway.

Cheapest check of all, and you can do it in the next five minutes without an admin. Look at the data rather than at the metadata. If the entities carry a load timestamp, or you know the maximum source date they should have picked up, that tells you whether anything landed on 30 July.

Do the tables themselves show data from that week?