Some tables and views timing out in Power Apps connecting to Azure SQL Server

Question

Some tables and views timing out in Power Apps connecting to Azure SQL Server

AY 36

Hi

Today we've been experiencing a timeout issues in a Power App which connects to Azure SQL Server. Below is the error message on one of the queries.

User's image

This connection has been setup for roughly 3 years without issues but today these errors.

Note that some other tables have not errored.

I've checked the performance of the Azure SQL Server and it is no where near capacity.

Any ideas?

Thanks in advance.

AY 36 Reputation points

2026-04-21T16:42:09.46+00:00

Having run the same queries on SQL Server Management Studio the response is almost instant. Why would Power Apps so slow and timing out? Also how do I extend the timeout on the SQL connection in Power Apps?
SAI JAGADEESH KUDIPUDI 2,635 Reputation points Microsoft External Staff Moderator

2026-04-28T11:55:40.8433333+00:00
Hi AY,

Thanks for sharing the XEvent output and the additional context — that’s very helpful.

From what you’ve described, this looks like a classic case of:

Queries running fast in SSMS but timing out from the application (Power Apps)

even though the Azure SQL database itself is not under resource pressure. 1. Power Apps timeout behavior

The SQL connector used by Power Apps has a fixed execution timeout (~30 seconds). If a query does not return within that time, the client cancels it.

So even if the query eventually completes, Power Apps will still throw a timeout. 2. XEvent Profiler output (your screenshot)

What you’re seeing is normal:

The initial queries (schema, metadata, etc.) are expected from client tools like Power Apps.

The large “logout” duration is not query execution time — it represents the total session lifetime.

Also note: durations are in microseconds, so the values are not as large as they appear.

So nothing in that trace suggests a server-side issue. 3. Why SSMS is fast but Power Apps is slow

This usually comes down to different execution plans, caused by differences in session settings and how queries are submitted.

The most common causes are:

Different SET options (especially ARITHABORT)

Parameter sniffing

Plan caching differences

You can test this by running the query in SSMS with:

SET ARITHABORT OFF; -- then run the exact query as sent from Power Apps

If the query becomes slower, it indicates a plan mismatch between SSMS and Power Apps. 4. Confirming client-side timeouts

You can validate whether Power Apps is cancelling queries using Query Store:

SELECT TOP 50 qt.query_sql_text, rs.last_execution_time, rs.execution_type, rs.last_duration/1000000.0 AS duration_sec FROM sys.query_store_query_text qt JOIN sys.query_store_runtime_stats rs ON qt.query_text_id = rs.query_text_id WHERE rs.execution_type = 3 ORDER BY rs.last_execution_time DESC;

execution_type = 3 indicates client-aborted executions, which aligns with timeout behavior.

Reproduce the application plan Run the query in SSMS with SET ARITHABORT OFF Ensure the query text matches exactly Stabilize/optimize the query
Review execution plan differences Add or adjust indexes Update statistics Simplify complex views if applicable **Ensure execution completes under 30 seconds** Power Apps timeout cannot be extended Move heavy logic into: Stored procedures Indexed views Pre-aggregated tables **(Optional) Check for intermittent blocking** Use DMVs like `sys.dm_exec_requests` to identify blocking sessions

There’s no indication of a capacity issue on Azure SQL.

The behavior is most likely due to execution plan differences between SSMS and Power Apps.

Since the Power Apps timeout is fixed, the resolution is to optimize or stabilize the query plan so it consistently completes within the timeout window.

Microsoft References Links:

https://learn.microsoft.com/power-apps/maker/canvas-apps/connections/connection-common-data-service#limits

https://learn.microsoft.com/azure/azure-sql/database/troubleshoot-query-timeouts

https://learn.microsoft.com/sql/t-sql/statements/set-arithabort-transact-sql

https://learn.microsoft.com/sql/relational-databases/system-catalog-views/sys-query-store-runtime-stats-transact-sql

https://learn.microsoft.com/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql
SAI JAGADEESH KUDIPUDI 2,635 Reputation points Microsoft External Staff Moderator

2026-05-03T09:32:42.49+00:00

Hi AY,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

2 answers

Your answer

AY 36 Reputation points

2026-04-21T16:42:09.46+00:00

Having run the same queries on SQL Server Management Studio the response is almost instant. Why would Power Apps so slow and timing out? Also how do I extend the timeout on the SQL connection in Power Apps?
SAI JAGADEESH KUDIPUDI 2,635 Reputation points Microsoft External Staff Moderator

2026-05-03T09:32:42.49+00:00

Hi AY,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Answer 1

Erland Sommarskog 133.9K MVP Volunteer Moderator

First, I have no experience of Azure Power Apps myself. It may be that Power Apps are submitting extra queries under the covers and these are the ones timing out. You can use the XEventProfiler in SSMS to determine if that could be the case.

More, generally, the experience Slow in the Application, Fast in SSMS is not unheard of. There are several reasons why this can happen. One thing you can try when you get these timeouts in the Power Apps is to first run SET ARITHABORT OFF before you run the query in SSMS. It is also important to run the query exactly as it is submitted from Power Apps, including spacing and all. What you want is to find the same cache entry that the application uses. If you get a new cache entry, you may get a different plan from the existing one.

For a lot longer discussion on this problem, I have an article on my web site with the title Slow in the Application, Fast in SSMS? where I discuss these problems in more details and possible solutions.

AY 36 Reputation points

2026-04-23T14:31:50.7766667+00:00

Could I get a little help with the XEventProfiler Output.So i setup XEventProfiler and then loaded the Power App. As well as the queries I was expecting there seem to be a lot of the first few rows which is non specific. Is this normal behaviour?

Also the duration of "Logout" of the last row seems awfully long. This big number occurred a couple of times during the load up process.

Thanks for any advice.
Erland Sommarskog 133.9K Reputation points MVP Volunteer Moderator

2026-04-23T21:23:24.8+00:00

Yes, there will be some noise. Particularly, if you cannot avoid that other things are running at the same time as the Logic App. Then it can be quite difficult to discern what is what. If you can set the application name in the connection string, this can help to filter. (There are some filter abilities in the Watch Live Data tab.)

The durations you see are in microseconds, so there is nothing alarming in the screenshot. The very high number for the logout, is not how long time the logout operation took, but it is the total time the session was connected.

Answer 2

The error indicates a SQL timeout: the query against specific tables/views isn’t completing within the allowed time, even though the database isn’t at overall capacity. Timeouts can be caused by:

Connectivity issues between Power Apps and Azure SQL (transient or network-related)
Long‑running or blocked queries on those particular tables/views
Resource limits being hit at database or server level (for example, worker threads, sessions, locks), even if CPU/DTU looks low

Use the following steps to narrow down and mitigate the issue.

Confirm it’s a connectivity/timeout issue
- The message pattern matches Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. which is a standard SQL timeout.
- Follow the guidance for timeout errors: increase the timeout and see if the operation eventually succeeds. If it does, treat it as a network/latency issue and investigate connectivity.
Check and harden connectivity
- From a client close to the Power Apps region (for example, a VM or workstation), test connectivity to the Azure SQL server on port 1433 using tools like Test-NetConnection as shown in the Power Apps + Azure SQL troubleshooting guidance.
- If connection succeeds but is slow or intermittent, work with networking to address latency or packet loss.
- Ensure firewall and networking settings on the Azure SQL server are correct (for example, “Allow Azure services and resources to access this server” enabled if appropriate, and correct client IPs allowed).
Increase connection timeout and add retry logic in the calling layer
- For applications connecting to Azure SQL, use at least a 30‑second connection timeout and implement retry logic for transient failures. This is recommended for cloud-connected apps and helps ride out short service or network blips.
Investigate query behavior on the affected tables/views
- Because only some tables/views are timing out, focus on those queries:
  - Check for blocking: long transactions or cascading operations on related tables can block reads/writes and cause timeouts.
  - Look for long‑running queries or complex views that may need optimization (indexes, query rewrite, batching).
- If the issue is related to Dataverse plug‑ins or other upstream logic writing to these tables, review for blocking patterns, large cascades, or operations on newly created tables/columns where indexing is still stabilizing.
Check for resource governance or transient service issues
- Even when overall utilization looks fine, specific resource limits (worker threads, sessions, locks, database size) can be hit and cause errors or slowdowns. Review for errors such as 10929, 40544, 40549, or 40550 in SQL error logs or client logs.
- Also check for transient fault errors (for example, 40197, 40501) around the timeouts. If present, ensure retry logic is in place and review Azure status and Resource Health for any transient platform issues.
If the problem persists
- Collect timestamps, error codes, and correlation IDs from the failing operations.
- Enable diagnostic logging on the app and Azure SQL to capture detailed error and performance data.
- If timeouts continue beyond transient periods or occur frequently, open an Azure support request with the collected data for deeper investigation.

References:

Share via

Some tables and views timing out in Power Apps connecting to Azure SQL Server

2 answers

Your answer