Forum Discussion
Power BI Gen1 Dataflow scheduled refresh retried?
Hi,
In the early hours of this morning, 2 am, the usual gen1 dataflows refreshes were triggered as scheduled. One of these failed with "internal error" for one of the tables. However, what I didn't expect was for the refresh to be triggered again 5 minutes later, and this time it was successful.
Have done some quick searches I understand that there isn't a built-in retry for scheduled gen1 dataflows.
Has anyone else seen this happen?
Is it the normal expected behaviour? (I don't want to assume it will work like this every time if not).
Cheers Phil
[Refresh history for reference]
That second run 5 minutes later strongly suggests one of these internal behaviors:
- Transient failure recovery at the service layer
The “internal error” classification usually maps to ephemeral issues (capacity pressure, backend compute node recycling, connector timeouts). The Power BI service can occasionally re-queue or replay jobs when it detects infrastructure-level faults. - Scheduler reconciliation / orphaned job recovery
If the first attempt failed in a non-clean way (e.g., partial execution state), the scheduler may enqueue a follow-up execution to ensure consistency. - Capacity load balancing effects
Especially around 2 AM (a common refresh window), capacity contention can cause failures followed by quick resubmission once resources free up.
None of these are documented guarantees
- Transient failure recovery at the service layer
2 Replies
- andrewsommer
Super User
That second run 5 minutes later strongly suggests one of these internal behaviors:
- Transient failure recovery at the service layer
The “internal error” classification usually maps to ephemeral issues (capacity pressure, backend compute node recycling, connector timeouts). The Power BI service can occasionally re-queue or replay jobs when it detects infrastructure-level faults. - Scheduler reconciliation / orphaned job recovery
If the first attempt failed in a non-clean way (e.g., partial execution state), the scheduler may enqueue a follow-up execution to ensure consistency. - Capacity load balancing effects
Especially around 2 AM (a common refresh window), capacity contention can cause failures followed by quick resubmission once resources free up.
None of these are documented guarantees
Wow andrewsommer , a fantastic and comprehensive response 😀. Thanks for this and I'll build my own retry workflow.
- Transient failure recovery at the service layer
