Power BI Service: DirectQuery (Kusto) visuals fail online but work fine in Desktop

[Semail]

Hi everyone,

I’m facing an issue with a Power BI FinOps dashboard using DirectQuery to Azure Data Explorer (Kusto).

• The report works perfectly in Power BI Desktop
• Dataset refresh in the Service succeeds
• But when loading the report online, visuals fail with inconsistent errors

 

Errors observed

• Sometimes one visual shows
  “Query has exceeded the available resources / QueryTimeoutExceeded”,
  while others show “Error fetching data for this visual”
• Other times, all visuals show only
  “Error fetching data for this visual”

 

What I checked

• Data source timeout → not set
• Query timeout → not set
• Visual query limits (Desktop, current file) → not set

So there are no explicit timeout limits configured.

 

Question

Is this a known Power BI Service limitation with DirectQuery + Kusto, especially for larger FinOps datasets and multiple DAX-based visuals?

Any recommendations to avoid this behavior?

I’ve attached screenshots of both error messages for reference.

Thanks in advance for any insights or advice!

[v-achippa]

Hi @Semail,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @mh2587 and @cengizhanarslan for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[Semail]

Hi everyone @v-achippa @cengizhanarslan @mh2587 ,

thanks a lot for the feedback so far - really appreciated!

I’ve verified that there are no query or visual limits configured.

- Regarding query result caching, as far as I understand it, it only works for Import semantic models on Premium/Embedded, while our model is DirectQuery, so I think this doesn’t apply in our case.

- The pre‑aggregation / materialized views in Kusto approach makes sense, but our Kusto setup is based on a standard FinOps template and is not directly managed by me, so changes there may be limited. At this point, the big question is also which part should be adjusted and how, without breaking the standard setup. 

That’s why I was hoping for alternative options that don’t require changes in Kusto.

If Kusto changes are not feasible, are there any Power BI–side optimizations you would recommend for DirectQuery scenarios?

Thanks again! 🙂

[v-achippa · Accepted solution]

Hi @Semail,

Thank you for the detailed response. Here the issue is related to the DirectQuery in the service because of the strict resource and concurrency limits compared to desktop. Since each visual sends its own query, multiple complex visuals running in parallel can exceed those limits and error occurs.

Since kusto changes are limited in your case, please try the below steps on the power bi side:

• Reduce the number of visuals per page to limit parallel queries
• Simplify DAX measures to avoid complex query translation
• Avoid high cardinality slicers and heavy cross filtering
• If possible, consider a hybrid model like Import with DirectQuery to reduce the load

Thanks and regards,

Anjan Kumar Chippa

[v-achippa]

Hi @Semail,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution I have  provided for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[cengizhanarslan]

Option 1) Enable query result caching

In Power BI Service semantic model settings → DirectQuery → enable Query caching. This serves repeated identical queries from cache rather than hitting Kusto every time, dramatically reducing concurrent load.

Option 2) Optimize the KQL queries generated by your DAX measures

Open DAX Studio, connect to your semantic model, and use Server Timings to capture the KQL queries Power BI sends to Kusto. Long-running or unoptimized KQL is the most common cause of QueryTimeoutExceeded. Simplify measures that generate complex nested KQL, avoid high-cardinality slicers that force full scans, and use pre-aggregated materialized views in Kusto where possible.

Option 3) Consider materialized views or pre-aggregation in Kusto

For FinOps data that aggregates large cost datasets, create Kusto materialized views that pre-aggregate the most common query patterns. Power BI then hits the materialized view instead of scanning raw data, which reduces both latency and resource consumption significantly.

[mh2587]

You need pre aggregation of the data or increase the queryexecute time