Two of many models fail scheduled refresh, with gateway unreachable error, pass manual refresh

[PhilSmith]

I have two models that will not refresh on schedule.  Other models do.  These models refresh manually no problem.  I have moved schedules around, reduced the number of models refreshing at that same time, it is just these two models.  
"Gateway Unreachable" for different tables, the same tables used in other models that refresh just fine, at the same time.

Suddenly Power Bi Pro is not enough to get tech support from microsoft?  Since when?

Any ideas?

Phil

[Poojara_D12]

Hi @PhilSmith 

You're encountering a frustrating issue where two specific Power BI models fail to refresh on schedule, despite refreshing successfully when done manually. These models use the same tables as others that refresh without problems, and you've already tried logical steps like staggering refresh times and reducing concurrent loads. The error you're seeing, "Gateway Unreachable," typically suggests a problem with connectivity between the Power BI Service and the on-premises data gateway, but in this case, it's inconsistent since other datasets using the same tables and gateway work fine. This points more towards a potential gateway service glitch, network interruption, or resource contention affecting just these two models during scheduled runs.

As for Microsoft support, you're right to feel surprised—Power BI Pro users used to have access to standard support. However, in recent years, Microsoft has shifted its model, and now Pro users generally have access only to community support unless their organization has a paid support plan (like Premier, Unified, or Fabric support). Full technical support for troubleshooting gateway and refresh issues typically requires Power BI Premium or Fabric capacity or a paid support plan tied to your tenant. This change has led many organizations to reassess their support needs based on the criticality of their Power BI deployments.

[Nasif_Azam]

Hey @PhilSmith ,

You have two Power BI models that:

• Fail on scheduled refresh with “Gateway Unreachable” errors.

• Refresh manually without issues.

• Use the same tables as other models that refresh successfully.

• Other models using the same data and gateway are not affected.

You’ve already tried:

• Adjusting refresh schedules.

• Reducing concurrent refreshes.

1. Gateway Resource Bottlenecks

Even if other models work fine, if these two are larger or more complex, they may time out or fail to reach the gateway when multiple models are scheduled.

Suggestions:

• Temporarily isolate these models (no concurrent refreshes).

• Stagger refresh with at least a 15-20 min gap.

• Increase timeout or memory if you manage the gateway (especially for on-premises data gateway in personal mode).

2. Query Folding or Transformation Differences

Manual refreshes can sometimes succeed because of different execution paths compared to scheduled refreshes.

Suggestions:

• Check Power Query steps in these models.

• Ensure query folding is working where applicable (right-click steps → “View Native Query”).

3. Gateway Version & Service Account

Sometimes a stale gateway version or a service account authentication lapse causes odd issues.

Suggestions:

• Go to the Power BI Service → Manage Gateways.

• Ensure the gateway is updated.

• Re-authenticate the data source connections used by the failed datasets.

4. Dataset-Specific Issues

Some models might:

• Use different credentials.

• Call external APIs or have custom connectors with timeout issues.

Suggestions:

• Review dataset settings for those models.

• Run Fiddler or gateway logs for failed scheduled refresh attempts to inspect errors.

5. Advanced Diagnostics

• Go to the Power BI Admin Portal → Audit Logs to check gateway connectivity details.

• Check refresh history for detailed failure stack.

• Enable diagnostics logs on the gateway to trace what happens during scheduled refreshes.

 

If none of the above work:

1. Create a duplicate of the model, simplify the query, and test scheduled refresh.

2. Create a test Power BI workspace and isolate the model there to rule out workspace-level issues.

3. If you suspect gateway overload, consider running the gateway on a separate dedicated machine temporarily.

If you found this solution helpful, please consider accepting it and giving it a kudos (Like) it’s greatly appreciated and helps others find the solution more easily.

Best Regards,
Nasif Azam

[BhavinVyas3003]

The “Gateway Unreachable” error during scheduled refresh is often due to resource contention, network instability, or query complexity—especially when multiple models refresh at the same time.

• Update the on-premises gateway to the latest version.

• Reschedule the two failing models during off-peak hours (e.g., 2–4 AM) to reduce load.

• Review and simplify queries in those models if they are large or have merge/join operations.

• Verify credentials and data source mapping in Power BI Service > Dataset > Settings > Gateway connection.

• Check gateway logs (C:\Program Files\On-premises data gateway\logs) to confirm cause—look for timeouts or memory errors.

[PhilSmith]

I have isolated one, and it made no differnce.  There is one query that is as simple as it can be, consisting of about 15 unions.  This is handled in the MYSQL server.  I will try to cut this down and see if that gets me anywhere.  

The error log is not user friendly.  Any pointers or links to help me decode the error logs?

Thanx

[v-tejrama]

Hi @PhilSmith ,

Thanks for reaching out to the Microsoft fabric community forum.

I reproduced the issue by creating two PBIX files with slightly different datasets, published to the Power BI Service, both using the same on-premises data gateway.

Scheduled both to refresh at the same time. Manual refreshes worked fine, but scheduled refreshes sometimes failed with “Gateway Unreachable,” especially when I reduced system resources or disrupted the network.

Gateway logs (C:\Program Files\On-premises data gateway\logs) confirmed the failures.

It’s likely due to resource limits, network instability, or complex queries causing overload during scheduled refresh.

If the response has addressed your query, please Accept it as a solution and give a 'Kudos' so other members can easily find it.

Best Regards,
Tejaswi.
Community Support

[PhilSmith]

I don;t think resource limits, because I have far larger Models that work fine.  I don't think network instability, because all of my models use the same two sources, and only these two fail every single time.  I do have one query that is pretty complex, but if it refreshes manually, then it would refresh on a schedule if it is the only model in that time slot.  I will play with the query, try cutting it down some, to see what happens.

Thanx

[v-tejrama]

Hi @PhilSmith,

You're absolutely right if larger models and the same sources work fine under similar conditions, that helps narrow things down. Since the models refresh manually without issue, it does suggest that the issue is not with the data sources or network per se, but possibly with how the gateway handles scheduled refresh for these specific models.

A few more focused things you might consider:

1. Query Load Timing  
   Even if a query is complex and refreshes manually, scheduled refreshes have tighter constraints (e.g., execution time limits, gateway throttling, concurrency). It's worth checking if the query has nested or looping logic, or non-foldable steps that might strain the gateway during automated execution.

2. Gateway Concurrency and Limits  
   Try isolating the scheduled refresh for one of the failing models (e.g., schedule it 5–10 minutes apart from everything else) to fully rule out any contention or throttling at the gateway level.

3. Gateway Logs and Performance Counters  
   Dive deeper into the gateway logs during the time of scheduled failure especially PerformanceCounter*.log and EnterpriseGateway*.log.

Look for memory pressure, CPU usage spikes, or gateway crash/restart messages. Even though larger models work, the specific transformation logic of these two might trigger memory or thread pool issues.

4. Test Gateway Recovery Mode  
   In Power BI Service > Manage Gateways > Gateway Cluster Settings, try enabling “Allow user's cloud data sources to refresh through this gateway cluster” if applicable, or test assigning a different gateway if available.

5. Query Folding Check  
   Try using the “View Native Query” option in Power Query Editor on the complex query. If folding is broken early, consider optimizing joins or filters to push as much work as possible back to the source.

If this response helps, please consider marking it as a solution and giving it a Kudos, so others can find it more easily.

Best regards,  

Tejaswi  
Community Support

[PhilSmith]

Hello again,

I am unable to find the setting you suggested under "Test Gateway Recovery Mode ."  I would try it if I could find it.  I do not have another gateway to try.  

Query folding is not an issue, this is a pure native MYSQL  query.

I have cut down my union query to a single union, and the query runs natively in under 2 seconds.  It fails when it is the only thing scheduled, but always refreshes in the service if I hit it manually.  What I have now is not in any way resource intensive.  I have looked at the gateway logs, and looking through the cybergreek, I do not see any evidence of a problem, not even connected to the actual table.  an Example:

Data source error: {"error":{"code":"DM_GWPipeline_Client_GatewayUnreachable","pbi.error":{"code":"DM_GWPipeline_Client_GatewayUnreachable","parameters":{},"details":[],"exceptionCulprit":1}}} Table: Brand.
Cluster URI: WABI-WEST-US-C-PRIMARY-redirect.analysis.windows.net
Activity ID: 11acffe3-c0e8-46d1-bd08-0709cf5d3ce5
Request ID: 2dd29f9c-36a6-4742-b829-fe1848d07974
Time: 2025-06-25 10:17:57Z

It's a different table each time. but same error.  Brand is a 20 record 11 column table.

Thanx

Phil

[GilbertQ]

Hi @PhilSmith 

The above error indicates that the Power BI service cannot connect your gateway for some reason. I understand you say it is connecting successfully to other data sources. If you can, please confirm that the gateway is running the latest version. And when you log into the gateway, you can see that it is connected successfully.

[PhilSmith]

Hello.

I am not ignoring you.  The biggest point behind these two models as a 15 union query.  I have been cutting that down, removing unions, to see if thast is the issue.  Unfortunately, I have only been able to create a single time slot that does not have something else refreshing it, so I get one test per day.  (Our gateway does not operate overnight.)

Even at full size, the query itself run against the same server took about a minute and 20 seconds to complete, and so far cutting it down to size has not helped, I thin, my last test will run today.  

The sticking point is that I can run a manual refresh in the service with two or three other models refreshing, (bigger models) with no problem.  I not sure what the difference is between a scheduled refresh and a manual refresh in the service.  I would think it is the same process.

I will let you know what I find, and if I get it fixed.

Phil

[v-tejrama]

Hi @PhilSmith,

Thanks for your detailed reply it really helps.

I’ve seen a similar issue before and was able to test it myself. The problem usually comes from how Power BI handles scheduled refreshes compared to manual ones. Scheduled refreshes use the on premises gateway and are more strict about time and resources, especially if other models are refreshing at the same time.

In my case, I had a model with many UNION queries like yours, and it only failed during scheduled refresh but worked fine when I refreshed it manually. What helped me was changing the refresh time so it didn’t run with other heavy models, breaking the UNION into smaller steps with "disable load", and moving some of the logic to a Power BI Dataflow.

Also, check if the machine running your gateway has enough memory and CPU, and make sure the gateway is updated and restarted before the refresh window.

Manual refresh is more flexible, but scheduled refresh can fail if things get too busy.

Hope this helps you and let  me know how it goes

Thank you.

[PhilSmith]

Thanx for the response.  I am confused about something.  You say that scheduled refreshes use the on premise gate like a manual refresh does not.  To be clear, I do not mean a refresh in the desktop, I mean "Refresh Now" option within the service

I have cut it so it is very small, and most of the time, the table it fails on, (different each time) is a small table.  I have far larger models, that all refresh just fine on a schedule.

[v-tejrama]

Hi @PhilSmith,

I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.

If the response answered your query, kindly “Accept as Solution” and Give “Kudos” to help others in the community benefit from it as well.

Thank you.

Tejaswi.

[v-tejrama]

Hi @PhilSmith ,

I hope the information provided has been useful. Please let me know if you need further clarification or would like to continue the discussion.

If your question has been answered, please “Accept as Solution” and Give “Kudos” so others with similar issues can easily find the resolution.

Thank you.

[GilbertQ]

Hi @PhilSmith 

Could it possibly be the reason the schedule refresh is filing is that the refreshes are consuming too many resources on your gateway? What happens if you try refresh them one at a time? Does it refresh successfully? If it does, it potentially means you either need to refresh them 1 at a time or increase the hardware on your gateway.

[PhilSmith]

I put it in it's own timeslot yesterday.  Where I have as many as four similar models refreshing at the same time wth no problems, this one, all by itself, still failed to refresh, with teh same error.  I will keep it this way  until I get it fixed.  I expect tomorrow I will get the same error, but on a different table.