Learn how to systematically find and fix Canvas app performance bottlenecks using Power Apps Monitor, custom Trace() instrumentation, and Azure Application Insights. Move from guessing to measuring with real production telemetry and KQL queries that expose exactly where your app is slow and why.
Your Canvas app passed UAT. Users loved the demo. Then it went to production with 400 concurrent users pulling from a SharePoint list with 80,000 rows, and now the ops team is getting Slack messages every morning about the "slow app." Screens take 8 seconds to load. The gallery flickers. Someone submits a form and nothing happens for 12 seconds. You open the app in the editor, click through it yourself, and everything feels fine. You're now staring at the gap between development-time intuition and production-scale reality — and that gap is exactly where most Canvas app performance work lives.
Performance profiling in Canvas apps is uniquely tricky because the platform hides a lot. Unlike a Node.js API where you can attach a profiler and watch the call stack, Power Apps abstracts away the execution model. Most developers end up guessing — removing formulas one by one, switching data sources, adding loading spinners — without ever confirming what the actual bottleneck is. This article is about replacing guessing with evidence. By the end, you'll be able to systematically capture, analyze, and act on real performance data from your Canvas apps using Power Apps Monitor, custom telemetry patterns, and Azure Application Insights.
What you'll learn:
Trace() and structured logging patternsThis lesson assumes you're already comfortable building Canvas apps with complex formulas, data sources, and multi-screen navigation. You should have:
Before you can profile anything effectively, you need a mental model of what is actually executing. Canvas apps are not web apps in the traditional sense — there's no DOM manipulation, no JavaScript runtime you control, and no server-side rendering pipeline to inspect. What you actually have is a declarative formula engine running inside the Power Apps player runtime, which is itself a web application hosted at make.powerapps.com or inside Teams.
When a user opens your app, the player runtime fetches the app definition (a binary-compiled representation of your app's formulas and assets), initializes the screen graph, and begins evaluating formulas in dependency order. Every property of every control — Visible, Items, Default, Color, X, Y — is a formula. The engine tracks dependencies between formulas and re-evaluates downstream formulas when upstream values change. This is the reactive model that makes Canvas apps feel alive, and it's also the source of most performance problems.
Three distinct phases contribute to perceived performance:
Load time — The time from a user clicking "open app" to the first interactive screen being visible. This includes fetching the app package, loading assets, evaluating App.OnStart, and rendering the initial screen.
Navigation time — The time between a user tapping a navigation button and the target screen becoming interactive. This includes evaluating the new screen's OnVisible formulas and hydrating its controls.
Interaction time — The time between a user action (button press, gallery selection, text input) and a visible response. This includes formula evaluation, data source calls, and re-render.
Most "slow app" complaints map to one of these three phases. Your profiling strategy needs to capture data at each phase to identify which one is actually causing pain.
Power Apps Monitor is the official debugging and profiling tool, accessible from the maker portal at make.powerapps.com. Most developers know it exists and have maybe looked at the network tab. Few use it to its full potential.
Here's the thing most documentation misses: Monitor can attach to published apps running in production, not just apps open in the editor. This matters enormously because the editor environment has fundamentally different performance characteristics — it injects the editing runtime, the formula bar, the tree view, and dozens of other components that change how the app behaves.
To attach Monitor to a production session:
You are now watching a real production execution in real time. Everything that executes — every formula evaluation, every network call, every error — appears in the Monitor log as the user interacts with the app.
The Monitor event stream is organized into event types. The ones that matter most for performance work are:
Network — HTTP requests made by the app. Each row shows the URL, method, status code, duration (in milliseconds), and the request/response body. This is where you'll find slow SharePoint queries, slow Dataverse reads, and throttled connector calls.
Formula — Evaluations of significant formulas. Not every formula evaluation appears here (trivial calculations are silent), but data-source-touching formulas and complex functions like Filter(), LookUp(), Sort(), and Collect() do.
UserAction — Button presses, navigation events, gallery selections. These serve as anchors in the timeline that let you correlate user behavior with subsequent formula and network events.
Error — Formula errors, delegation warnings that became runtime failures, connector errors.
Publish — Metadata about the app version running in the session.
When you're investigating a slow screen load, find the UserAction event for the navigation (or the Publish event for the initial load), then look at every Network and Formula event that follows until the screen is interactive. The duration of each event is shown in the "Duration (ms)" column. Sort by duration descending and you immediately see your most expensive operations.
The single most valuable thing Monitor shows you is N+1 query patterns. This is a problem you cannot detect by looking at formulas — you have to see the actual HTTP calls being made.
Consider a gallery bound to a SharePoint list of 200 work orders. Each gallery item has a label that shows the name of the assigned technician, pulled from a separate "Employees" list using a formula like:
LookUp(Employees, ID = ThisItem.AssignedTechnicianID, FullName)
In the editor, with 10 items visible, this works fine. In Monitor on a production session with the gallery fully loaded, you'll see 200 separate HTTP requests to the Employees list — one for each item. Each request takes 200-400ms. The gallery is serializing 200 network round trips. That's where your 12-second load time is going.
This is the N+1 problem, and you would never know it was happening without watching the network trace. The fix is to pre-load the Employees collection on screen load and use a local LookUp() against the in-memory collection instead. We'll cover this architectural pattern in detail later.
Tip
In Monitor, use the "Filter" option to show only events from a specific event category. When you're hunting for network performance issues, filter to "Network" only and sort by "Duration (ms)" descending. The top five rows almost always contain your bottleneck.
One underused feature: you can export a Monitor session as a JSON file using the download button in the toolbar. This lets you:
When you export two sessions and compare the "Duration (ms)" values for the same event sequences, you can quantitatively confirm whether a change you made actually improved performance. This is how you avoid the trap of making a change, feeling like the app "seems faster," and calling it done.
Monitor is excellent for interactive debugging sessions, but it has two significant limitations for production work at scale: it requires a live watcher, and the data doesn't persist anywhere by default. For persistent, queryable telemetry, you need to instrument your app with Trace().
Trace() is a Canvas app function that emits a custom event to the Monitor log (during a monitored session) and, critically, to Azure Application Insights if you've connected it. The signature is:
Trace(message, severity, customRecord)
Where:
message is a string identifier for the eventseverity is one of TraceSeverity.Information, TraceSeverity.Warning, TraceSeverity.Error, or TraceSeverity.CriticalcustomRecord is an optional record (a Power Apps record literal) of custom properties you want to attachThe third parameter is where the real power lives. You can attach arbitrary structured data to each trace event, and that data becomes queryable dimensions in Application Insights.
Before you write a single Trace() call, design your schema. Ad-hoc telemetry is almost as useless as no telemetry — if every developer adds Trace() calls with different field names and formats, your queries become unmaintainable.
Here's a schema that works well for Canvas app performance telemetry:
// Naming convention for message: "ScreenName_EventType_Description"
// Standard custom properties:
{
screen: "WorkOrderList", // Which screen triggered the event
user: User().Email, // Who triggered it (be mindful of privacy)
sessionId: varSessionId, // A GUID generated at App.OnStart for correlation
appVersion: Param("appVersion"), // Passed as a query parameter for version tracking
durationMs: varLoadDuration, // Measured duration in milliseconds
recordCount: CountRows(colData), // Row counts for data operations
dataSource: "SharePoint_WorkOrders", // Identifies which data source was called
success: true, // Outcome flag
errorMessage: "" // Error detail if applicable
}
To generate a session ID at app start, put this in App.OnStart:
Set(varSessionId, Text(GUID()))
This gives you a correlation ID that lets you query Application Insights for all events from a single user's session — which is invaluable when you're reconstructing a slow user journey.
To measure how long a screen actually takes to become usable, you need to capture a timestamp when the screen starts loading and another when it's done. Here's the pattern:
In the screen's OnVisible property (the first thing that runs when the screen is navigated to):
// Record when loading started
Set(varScreenLoadStart, Now());
// Perform your data loads
ClearCollect(
colWorkOrders,
Filter(
WorkOrders,
Status = "Open" And AssignedRegion = varUserRegion
)
);
// Calculate duration and emit telemetry
Set(varScreenLoadDuration, DateDiff(varScreenLoadStart, Now(), TimeUnit.Milliseconds));
Trace(
"WorkOrderList_Screen_Load",
TraceSeverity.Information,
{
screen: "WorkOrderList",
user: User().Email,
sessionId: varSessionId,
durationMs: varScreenLoadDuration,
recordCount: CountRows(colWorkOrders),
dataSource: "SharePoint_WorkOrders",
success: true,
errorMessage: ""
}
)
Warning
Now() in Canvas apps does not give you sub-second precision in all runtime environments. For coarse-grained timing (seconds to tens of seconds), it works fine. For millisecond-level timing, use a combination of Trace() timestamps in Application Insights, which are timestamped with high precision at the time the event is received.
For individual data operations, create a consistent pattern. Here's a reusable approach for a Patch() call that creates a work order:
// In a button's OnSelect:
Set(varOperationStart, Now());
// Attempt the operation
Set(varNewWorkOrder,
Patch(
WorkOrders,
Defaults(WorkOrders),
{
Title: txtTitle.Text,
Priority: ddlPriority.Selected.Value,
AssignedTechnicianID: galTechnicians.Selected.ID,
Status: "Open",
CreatedBy: User().Email
}
)
);
// Check outcome and emit telemetry
If(
IsError(varNewWorkOrder),
Trace(
"WorkOrderDetail_Patch_Create",
TraceSeverity.Error,
{
screen: "WorkOrderDetail",
user: User().Email,
sessionId: varSessionId,
durationMs: DateDiff(varOperationStart, Now(), TimeUnit.Milliseconds),
dataSource: "SharePoint_WorkOrders",
success: false,
errorMessage: "Patch returned error - check connector permissions"
}
),
Trace(
"WorkOrderDetail_Patch_Create",
TraceSeverity.Information,
{
screen: "WorkOrderDetail",
user: User().Email,
sessionId: varSessionId,
durationMs: DateDiff(varOperationStart, Now(), TimeUnit.Milliseconds),
dataSource: "SharePoint_WorkOrders",
success: true,
errorMessage: ""
}
)
)
This pattern gives you both timing and outcome data for every significant operation. Over time in Application Insights, you can compute P50/P90/P99 latencies for each operation and identify which users or time windows show elevated latency.
This is where telemetry goes from "useful during a debug session" to "operational intelligence you can query at 2am when someone calls about a production incident."
In the Azure portal, create an Application Insights resource:
wsd-canvasapps-prod and choose "Workspace-based" as the resource mode (the classic mode is being deprecated)Tip
Use a single Application Insights instance for all your Canvas apps in a given environment (development, staging, production). This makes cross-app queries possible and reduces Azure billing complexity. Use custom properties like appName in your telemetry schema to filter between apps.
In the Power Apps maker portal, with your app open in the editor:
Once this is configured, every Trace() call in your app will send events to Application Insights as custom traces events. Additionally, Power Apps itself will automatically send some diagnostic telemetry about session starts, errors, and performance metrics — though this automatic telemetry is less structured than what you emit with Trace().
Warning
As of the current platform state, the Azure Application Insights integration in Canvas apps uses the instrumentation key, not the newer connection string. The instrumentation key is still functional, but be aware that Microsoft has announced that connection string-based configuration is preferred for new workloads. Monitor the Power Apps release notes for updates to this integration.
After publishing your updated app, open it, navigate through a few screens, perform some operations, and then return to your Application Insights resource in Azure. Navigate to "Logs" (the query interface), and run this basic KQL query:
traces
| where timestamp > ago(1h)
| order by timestamp desc
| take 50
You should see rows with your trace messages in the message column. Expand any row and click "customDimensions" — you should see all the properties you passed in the third argument to Trace().
If nothing shows up after 5 minutes, the most common causes are: the wrong instrumentation key, the app wasn't republished after adding the key, or the experimental feature wasn't saved. Recheck each step.
Now comes the part that separates performance professionals from people who have telemetry but can't use it. KQL (Kusto Query Language) is the query language for Azure Monitor and Application Insights, and it's genuinely pleasant to write once you understand its pipe-based structure.
Every KQL query starts with a table name, then applies a series of transformations separated by | (pipe) operators. Each pipe operator filters, transforms, or aggregates the data. Let's build the queries you'll actually use.
This query shows you the P50, P90, and P99 load times for each screen, sorted by P99 descending. Start with P99 — that's where your worst-affected users live.
traces
| where timestamp > ago(7d)
| where message endswith "_Screen_Load"
| extend
screenName = tostring(customDimensions.screen),
durationMs = todouble(customDimensions.durationMs),
userEmail = tostring(customDimensions.user)
| where isnotempty(durationMs)
| summarize
P50 = percentile(durationMs, 50),
P90 = percentile(durationMs, 90),
P99 = percentile(durationMs, 99),
Count = count()
by screenName
| order by P99 desc
If your WorkOrderList_Screen_Load shows P50=2100ms, P90=6800ms, P99=14200ms, you immediately know this screen has a long tail — most users have an acceptable experience, but a meaningful percentage are hitting something much worse. That asymmetric distribution is a classic sign of a delegation problem or a cold-start issue on a connector.
Sometimes slowness is user-specific (network conditions, device performance) and sometimes it's operation-specific (a query that returns too much data). This query helps you separate the two:
traces
| where timestamp > ago(7d)
| extend
screenName = tostring(customDimensions.screen),
durationMs = todouble(customDimensions.durationMs),
userEmail = tostring(customDimensions.user),
dataSource = tostring(customDimensions.dataSource)
| where isnotempty(durationMs) and isnotempty(screenName)
| summarize
AvgDuration = avg(durationMs),
MaxDuration = max(durationMs),
Samples = count()
by userEmail, screenName
| order by AvgDuration desc
| take 20
If the top rows all show the same user, investigate that user's device and network. If the top rows show many different users all hitting the same screen, the problem is in the operation, not the user.
A performance investigation often reveals errors disguised as slowness — timeouts that eventually return an error after 30 seconds. This query shows you your error rate trend:
traces
| where timestamp > ago(14d)
| extend
isError = customDimensions.success == "false" or severityLevel == 3
| summarize
TotalEvents = count(),
ErrorEvents = countif(tostring(customDimensions.success) == "false")
by bin(timestamp, 1h)
| extend ErrorRate = round(100.0 * ErrorEvents / TotalEvents, 2)
| order by timestamp asc
| project timestamp, TotalEvents, ErrorEvents, ErrorRate
Render this as a time chart in the Application Insights query editor to see if error rates spike at particular times — end of business day, Monday mornings after the weekend batch job runs, etc.
When a user reports that "the app was broken for me this morning," you can use their email and your session ID to reconstruct exactly what happened:
traces
| where timestamp > ago(24h)
| where tostring(customDimensions.user) == "jane.doe@contoso.com"
| extend
sessionId = tostring(customDimensions.sessionId),
screenName = tostring(customDimensions.screen),
durationMs = todouble(customDimensions.durationMs),
success = tostring(customDimensions.success)
| order by timestamp asc
| project timestamp, message, screenName, durationMs, success, sessionId
This gives you a chronological log of every telemetry event Jane triggered, grouped by session. You can see which screen she was on, what happened, how long each operation took, and whether anything failed.
Your telemetry schema includes recordCount. This query tells you whether load time correlates with how many records were returned — which would indicate a delegation or local processing problem:
traces
| where timestamp > ago(7d)
| where message == "WorkOrderList_Screen_Load"
| extend
durationMs = todouble(customDimensions.durationMs),
recordCount = toint(customDimensions.recordCount)
| where isnotempty(durationMs) and isnotempty(recordCount)
| summarize avg(durationMs) by
RecordBucket = case(
recordCount < 100, "0-99",
recordCount < 500, "100-499",
recordCount < 1000, "500-999",
"1000+"
)
| order by RecordBucket asc
If you see avg duration jump from 1200ms for the "0-99" bucket to 8500ms for the "1000+" bucket, you have a local processing problem — the app is pulling all records from the server and filtering/sorting them in the client. That's a delegation issue, and no amount of formula optimization will fix it. You need to push the filtering to the data source.
Armed with evidence from Monitor and Application Insights, let's look at the five problems you'll encounter most frequently, why they happen, and how to fix them structurally.
The most common cause of slow initial load is an App.OnStart that does too much. Every ClearCollect(), Collect(), and Set() call in App.OnStart executes sequentially before any screen renders. Developers put things here because "it only runs once" — but for the user, "once" means "before they can do anything."
What Monitor shows: A long string of sequential Network events immediately after app launch, with nothing user-visible happening. Total duration might be 15-30 seconds.
The fix — Lazy loading: Move data loads out of App.OnStart and into the OnVisible property of the screen that actually needs them. Only load what the first screen needs before it renders. Load everything else after the user is already interacting.
For data you genuinely need app-wide (like a user's role or preferences), keep it in App.OnStart but minimize it:
// App.OnStart - only essential global state
Concurrent(
Set(varCurrentUser, {
email: User().Email,
displayName: User().FullName,
role: LookUp(UserRoles, Email = User().Email, Role)
}),
Set(varAppConfig, LookUp(AppConfiguration, IsActive = true))
)
Note the Concurrent() wrapper. This executes both Set() calls in parallel rather than sequentially. For two calls that don't depend on each other, this can halve your OnStart time.
Delegation is Power Apps' way of telling the server "you do the filtering/sorting, don't send me everything." When a formula is not delegable, the server sends the first 500 (or 2000, if you've increased the limit) records, and then Power Apps filters that local collection in memory. If your actual dataset has 50,000 records, you're working with an invisible, silent truncation of your data.
What Monitor shows: A single large network response (sometimes 1-2MB of JSON for 2000 records) followed by correct-looking results in the UI, but incorrect counts — CountRows() returns 500 when you know there are more records.
What Application Insights shows: Your recordCount metric plateaus at exactly 500 or 2000 across all users, regardless of how much data they should see.
The fix: Rewrite non-delegable formulas. For SharePoint and Dataverse, the set of delegable functions is well-documented. The non-delegable ones you'll hit most often:
CountRows() on a filtered datasource (not delegable to SharePoint)Filter() with In operator against a collection (not delegable)Search() across multiple columns (partially delegable)Len(), Left(), Mid() inside Filter() (not delegable)For Search() across multiple columns in SharePoint, the delegable alternative is to use SharePoint's native search via a custom connector, or to pre-process and index a single combined search field in SharePoint itself.
For complex filtering that can't be made delegable, consider using Dataverse as your data source instead of SharePoint. Dataverse's delegation support is significantly more comprehensive.
We introduced this earlier. It deserves a full structural treatment.
What Monitor shows: Dozens to hundreds of sequential network requests, all to the same endpoint, all retrieving single records. Each request takes 150-400ms. A gallery with 100 items generates 100 lookups.
The fix — Pre-load and join locally:
// In Screen.OnVisible:
// 1. Load the primary collection
ClearCollect(colWorkOrders, Filter(WorkOrders, Status = "Open"));
// 2. Load the related collection (the one being looked up per item)
ClearCollect(
colTechnicians,
Filter(Employees, IsActive = true)
);
// 3. Create a joined collection using AddColumns
ClearCollect(
colWorkOrdersWithTechnicians,
AddColumns(
colWorkOrders,
"TechnicianName",
LookUp(colTechnicians, ID = TechnicianID, FullName),
"TechnicianPhone",
LookUp(colTechnicians, ID = TechnicianID, Phone)
)
);
Now bind the gallery to colWorkOrdersWithTechnicians. The LookUp() inside AddColumns() operates against colTechnicians, which is an in-memory collection — no network calls. Two network requests total instead of 102.
Warning
This pattern moves data loading time from "gallery scroll time" to "screen load time." Your screen will now take longer to show the first pixel, but it will be fully interactive when it appears. For large collections (>500 rows), communicate this loading state clearly with a LoadingSpinner or progress indicator.
Complex screens with many formulas can trigger re-render cascades — a single variable change causes dozens of formula re-evaluations, each of which may trigger further evaluations. The user experiences this as the screen "locking up" briefly after any interaction.
What Monitor shows: Long chains of Formula events with short individual durations but high aggregate duration. Nothing is slow in isolation, but everything adds up.
The diagnosis: Look for variables that are referenced by many controls. If varSelectedWorkOrder is referenced in 40 places on a screen, changing it triggers 40 formula re-evaluations. If those formulas in turn change other variables, you get cascading re-evaluations.
The fix — Consolidate into records:
Instead of 15 individual variables for the selected item's display state:
// Anti-pattern: many individual variables
Set(varSelectedTitle, galWorkOrders.Selected.Title);
Set(varSelectedStatus, galWorkOrders.Selected.Status);
Set(varSelectedPriority, galWorkOrders.Selected.Priority);
Set(varSelectedTechnician, galWorkOrders.Selected.TechnicianName);
// ...12 more of these
Use a single record variable:
// Better: one variable change, one dependency update
Set(varSelectedWorkOrder, galWorkOrders.Selected);
Then reference fields directly: varSelectedWorkOrder.Title, varSelectedWorkOrder.Status, etc. The dependency graph now has one variable instead of fifteen, reducing re-evaluation cascades significantly.
Buttons that perform several sequential operations — validate input, check business rules, write to SharePoint, send an email notification, write to an audit log — create a perceptible freeze while the user waits for each step to complete before the next begins.
What Monitor shows: 4-6 sequential network events after a button press, each waiting for the previous to complete. Total duration: 8-15 seconds.
The fix — Use Concurrent() for independent operations and Power Automate for post-write work:
For truly independent operations:
// Write to both lists simultaneously instead of sequentially
Concurrent(
Patch(WorkOrders, varDraftWorkOrder, {Status: "Submitted"}),
Patch(AuditLog, Defaults(AuditLog), {
Action: "WorkOrderSubmitted",
UserEmail: User().Email,
Timestamp: Now()
})
)
For post-write operations like sending emails, don't do them in the Canvas app at all. Use a Power Automate flow triggered by a SharePoint item change. The user's button press writes the record and returns immediately — the email sends asynchronously in the background via Power Automate. From the user's perspective, the operation is instant.
In this exercise, you'll instrument an existing Canvas app with telemetry, connect it to Application Insights, and use a Monitor session to identify a performance problem.
Setup: You'll need a Canvas app connected to a SharePoint list. If you don't have one ready, create a simple app with a gallery showing items from any SharePoint list with at least 200 rows.
Step 1: Create an Application Insights resource in Azure. Navigate to the Azure portal, create a new Application Insights resource in a resource group of your choice, and copy the instrumentation key from the Overview page.
Step 2: Connect the app to Application Insights. Open your Canvas app in the editor. Go to Settings, find the Azure Application Insights toggle under Experimental features, enable it, and paste your instrumentation key. Save the settings.
Step 3: Add a session ID variable. In App.OnStart, add Set(varSessionId, Text(GUID())). This is your correlation ID.
Step 4: Instrument your main screen. On your gallery screen, add the following to the beginning of Screen.OnVisible:
Set(varScreenLoadStart, Now())
And at the end of Screen.OnVisible (after your data loads), add:
Set(varScreenLoadMs, DateDiff(varScreenLoadStart, Now(), TimeUnit.Milliseconds));
Trace(
"GalleryScreen_Load",
TraceSeverity.Information,
{
screen: "GalleryScreen",
user: User().Email,
sessionId: varSessionId,
durationMs: varScreenLoadMs,
recordCount: CountRows(colYourCollection),
success: true
}
)
Step 5: Publish and open Monitor. Publish the app. Open Monitor from the maker portal. Generate a session link and open it in a separate incognito window. Navigate through the app, triggering your gallery screen at least five times.
Step 6: Analyze the Monitor network trace. In the Monitor window, filter to "Network" events only. Sort by Duration descending. Note the top three longest-running requests and write down: the URL, the duration, and whether you can identify which formula triggered it.
Step 7: Query Application Insights. Wait 5-10 minutes for telemetry to propagate. Open Application Insights Logs and run the screen load duration query from earlier in this article. Verify your events appear. Add a filter for tostring(customDimensions.sessionId) == "your-session-id" to see only your test session's events.
Step 8 (Challenge): In Monitor, look for any N+1 query patterns — multiple sequential requests to the same SharePoint list URL. If you find one, modify your app to pre-load the related collection and measure the improvement by running another Monitor session and comparing durations.
"My Trace() calls work in Monitor but nothing shows up in Application Insights." The most likely cause is the instrumentation key not being saved, or the app not being republished after setting the key. Verify in App Settings that the key is present. Republish, wait 10 minutes, and query Application Insights again. Also verify you're querying the right Application Insights resource — it's easy to have multiple and query the wrong one.
"My telemetry shows durationMs of 0 for all events."
This happens when Now() calls are evaluated at the same logical time step. Canvas apps batch formula evaluations within a single OnSelect or OnVisible call, and two sequential Now() calls within the same logical batch may return identical values. Workaround: use the timestamp of events in Application Insights for duration measurement instead of computing duration inside the app.
"Monitor shows fast response times but users say the app is slow."
This is often a rendering issue, not a data issue. If the data loads quickly but the screen has hundreds of controls or deeply nested galleries, rendering time adds latency that Monitor doesn't capture as network time. Consider reducing the number of visible controls on slow screens and using Visible = false (not DisplayMode = Disabled) to remove controls from the render tree when they're not needed.
"My Concurrent() call seems to run sequentially in some cases."
Concurrent() has undocumented limitations. It doesn't parallelize calls to the same data source — if you call ClearCollect(List1, ...) and ClearCollect(List2, ...) where both connect to the same SharePoint site, they may serialize anyway due to connection pooling. Verify parallelism using Monitor by checking if the network event start times overlap.
"Application Insights costs are higher than expected."
Every Trace() call sends data to Azure, and you're billed on data ingestion. If your app has many active users and you've instrumented every button press, you may generate significant telemetry volume. Use sampling by only calling Trace() for operations above a duration threshold, or for a random sample of users using Mod(Value(Right(varSessionId, 4)), 10) = 0 (traces 10% of sessions). Review the Azure Cost Management console for your Application Insights resource's ingestion volume.
"I can see network events in Monitor but can't tell which formula triggered them." Enable verbose logging in Monitor by clicking the settings icon (gear) in the Monitor toolbar and enabling "Include Power Fx formula events." This increases the verbosity of Formula events and often shows the formula that preceded a network call. The correlation isn't always perfect, but it narrows the search significantly.
"My P99 latency is much higher than P90, but I can't find a pattern."
High P99 with normal P90 is often caused by cold starts — the first user to hit a connector after a period of inactivity triggers a cold start penalty (sometimes 5-30 seconds for custom connectors). Query Application Insights for events where durationMs > P90_value and check the timestamp values — if they cluster at Monday morning, after midnight, or after holidays, you have a cold start pattern. Solutions include warm-up flows that ping the connector on a schedule, or switching to a connector with faster cold start behavior.
Performance profiling in Canvas apps requires combining three distinct tools for a complete picture: Power Apps Monitor for real-time, interactive debugging and network-level visibility; Trace() instrumentation for capturing performance context at the formula level; and Azure Application Insights for persistent, queryable telemetry at production scale.
The workflow you've built here — define a telemetry schema, instrument your app, query Application Insights with KQL, and correlate findings with Monitor network traces — gives you the same kind of evidence-based performance engineering that backend engineers take for granted. You're no longer guessing. You're measuring.
The five anti-patterns we covered — OnStart overload, delegation violations, gallery N+1 queries, re-render storms, and synchronous multi-step operations — cover the vast majority of Canvas app performance problems you'll encounter in practice. Each has a structural solution, and each solution is verifiable through your telemetry.
What to explore next:
The investment in telemetry and profiling infrastructure pays forward with every new feature you add. When the next performance complaint arrives, you'll have a query ready before the second Slack message lands.