Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

power-apps/10-licensing-and-performance/feature-app-performance-monitoring.md
feature-app-performance-monitoring.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Live monitor streams the events happening inside a running app — every network call, its duration, its response size, the formula that triggered it — either from a Studio session or from a published app a real user is playing. It's the tool that turns "the app is slow" into a list of requests with timings against them.

Key facts

  • Works for canvas apps in Studio and at runtime, and for model-driven apps covering page navigation, command execution and form issues.
  • Security role needed: Environment Admin or Environment Maker for canvas; System Administrator or System Customizer for model-driven.
  • The grid columns that do the work: Duration, Response size, Status (HTTP code), Result Info (the human translation — a 429 reads as "Too many requests"), Data Source, Control and Property.
  • Selecting an event opens four tabs: Details, Formula (the app formula that caused it), Request and Response (full HTTP, JSON viewable).
  • Invite shares a monitoring session with another maker in the same organisation. Connect user sends a link to an end user so support can watch their session live.
  • Some hosted and embedded scenarios don't support Live monitor. Microsoft documents alternatives — Application Insights, Dataverse logging tables, SharePoint list logging, on-screen diagnostics panels.
  • It pairs with the Power Fx Trace function, which is how you get your own markers into the stream.

When to use / skip

This is the first tool to reach for on any performance complaint, and it's free. The typical wins it surfaces are boring and large: the same data source fetched four times on OnStart, a timer control firing every second, a gallery pulling 2,000 rows to display 20, a lookup with no delegation returning everything. Where it stops being the right tool is anything about aggregate behaviour — how many users hit a problem, whether last Tuesday's release made things worse, what the 75th percentile load time is. That's Application Insights, and Live monitor won't answer it however long you stare at it.

Configuration decisions

  • Whether performance investigation happens in Studio (fast, but not representative of a real user's network and device) or against the published app with Connect user (slower to arrange, far more honest).
  • Whether the app is instrumented with Trace calls at the points you'll want markers, which has to be decided before you need them.
  • Whether support staff are given the Connect user workflow as a standard triage step, or whether it stays a developer tool.
  • What "acceptable" looks like numerically — agreed before the performance conversation, not during it.

Gotchas

  • Duration in Studio is not duration on a warehouse tablet over 4G. Studio timings systematically flatter the app, and the difference is where most performance disagreements live.
  • Live monitor shows you what happened, not what it cost. A 200ms call made 40 times looks fine per row and is the actual problem.
  • Response size is the column people skip and shouldn't. Fetching a wide table to display three columns is invisible in duration terms until the network is bad.
  • A 429 in the Status column is throttling, not a bug in the app. That points at request limits or a service protection limit, which is a different fix entirely.
  • The session is live only. Close the tab and the evidence is gone — screenshot or export before you start theorising.

Consultant notes

  • Run Live monitor on the app before the client complains, ideally at the end of build. Finding the four redundant OnStart calls yourself is a much better conversation than having a user find them.
  • Connect user is underused and is the single best answer to "it's only slow for Janet". Get it into the support runbook.
  • Set the expectation that Live monitor is for one session and Application Insights is for the population. Clients who've been shown one tool assume it does both jobs.
  • When a number is disputed, insist the measurement is taken against the published app on the device the users actually have. It changes the conclusion more often than not.

Sticky note: revisit if the advanced monitoring unsupported-scenario list shrinks, or if Studio gains a proper aggregate performance view.

Was this accurate?
Related
Canvas app performance01-canvas-appsApplication Insights for apps10-licensing-and-performanceMobile performance and sync07-mobile-and-offlineFormula performance patterns03-power-fx-and-logicModel-driven app performance02-model-driven-appsOffline for model-driven apps07-mobile-and-offline