{"id":9741,"date":"2020-06-24T02:45:51","date_gmt":"2020-06-24T09:45:51","guid":{"rendered":"https:\/\/cm-edgetun.pages.dev\/en-us\/power-platform\/blog\/power-apps\/use-monitor-to-debug-your-published-app\/"},"modified":"2025-06-11T07:58:33","modified_gmt":"2025-06-11T14:58:33","slug":"use-monitor-to-debug-your-published-app","status":"publish","type":"post","link":"https:\/\/cm-edgetun.pages.dev\/en-us\/power-platform\/blog\/power-apps\/use-monitor-to-debug-your-published-app\/","title":{"rendered":"Use Monitor to debug your published app"},"content":{"rendered":"

Reproducing and debugging issues that happen in your published app or in your live environments can be complex and time-consuming. It may be that the amount of data in your live system has grown and your data is now not presenting correctly (hint: delegation) in your app? Or performance has slowed down unexpectedly, and you need to understand why? Or a bug was introduced in your latest update? Whatever the reason, having a quick way to find the problem is invaluable. Debugging and understanding the events happening in your published app is our latest feature addition to Monitor.<\/p>\n

\u00a0<\/p>\n

To start debugging the published app, select an app from the app list in Power Apps<\/a> and then select Monitor<\/strong>\u00a0from the menu. In the Monitor, select Play published app<\/strong>. This will launch the published app in a new browser tab and connect it to your Monitor debug session. The Monitor starts capturing and displaying the events immediately from your app, including any warnings or errors that have occurred. Note, depending on when your app was last published, you may need to re-publish the app to connect it to the monitor.<\/p>\n

\u00a0\"\"<\/span><\/p>\n

You can also open Monitor from the Power Apps studio, just like you do today, and then select \u201cPlay published app\u201d<\/strong> from the top menu in Monitor. If you open the published app using this method, you’ll have your app connected to the same Monitor session twice. The app being edited in Power Apps Studio and the published app in the web player. Events from both the Power Apps Studio and the published app will be shown in the Monitor if you interact with the app using both options at the same time.<\/p>\n

\u00a0<\/p>\n

Debug Published app setting<\/h1>\n

If you want to view the source expressions in the monitor for the published app, you need to turn on a new setting to publish the expressions with the app. This is like generating a debug file in traditional development. Some of you may not want to publish your source expressions with your app, and that\u2019s OK. If you don\u2019t turn this on, you will still be able to see the events happening in your app but you won\u2019t be able to map these to specific expressions or formulas.<\/p>\n

\"\"<\/p>\n

What else is new?<\/h1>\n

We\u2019ve added new events and warnings in the Monitor, visual indicators for issues, and also new default fields in the events grid to help you understand the results of the various operations happening in your app.<\/p>\n

Result and Result Info<\/h3>\n

201? 403? 429? Hmmm? Previously, to understand the status of network operations displayed in the event log, you needed to know what the various status codes meant. We are now translating these statuses into the Result<\/strong> and Result Info<\/strong> fields. For example, a 429 will show an \u201cError\u201d<\/em> result and \u201cToo many requests\u201d<\/em> in the result info. Row colors also help to identify any errors and warnings quickly. We\u2019ve started populating these fields for network requests, but we will be extending the Result Info to show other high level event information such as custom Trace messages and warning details soon.<\/p>\n

\"\"<\/p>\n

\u00a0<\/p>\n

Filter, LookUp, First, CountIf, CountRows<\/h3>\n

If a function can be delegated to a data source but it wasn’t, you will see a warning event in the Monitor. For example,\u00a0 below we are using the LookUp function on a delegable data source. Lookup can be delegated, but it is using a selection formula that can\u2019t be delegated. Because of this, only the first portion (default 500 rows) of the data source will be retrieved and then the function applied. This may cause unexpected results in the app as the LookUp is working against an incomplete data set, and your app may display incorrect results. It will also impact performance, as the data needs to be first downloaded to the client and processed locally vs the query being run on the server. These warning will help remind you of the delegation limits and possibly the need to switch to delegable alternatives.<\/p>\n

\"\"<\/p>\n

\u00a0<\/p>\n

Navigation and Screen Load events<\/h3>\n

As you play your published app, Navigation <\/strong>and ScreenLoad<\/strong> events can help you further understand your app performance and what screens are taking the longest time to load. \u00a0Depending on how your app is designed, you may also see an InefficientControlReferences<\/strong>\u00a0performance warning.<\/p>\n

Let\u2019s dive into the InefficientControlReferences <\/strong>warning\u00a0a bit more. To help improve performance, screens are only initialized and loaded in memory as they are needed. However, if you have formulas that reference controls on other screens, this can force the app to load these screens immediately (if they are not already loaded in memory), rather than waiting until the user navigates to that screen. This can cause performance issues by slowing down your screen navigation and you should try and remove these references. Using variables or collections to store the values you are referencing on dependent controls, or passing the values using screen parameters are ways you can work around this issue.<\/p>\n

\"\"<\/p>\n

Viewing the details of the InefficientControlReferences<\/em> event will tell you the cross-screen control dependencies that have caused the additional screen(s) to load. In the example, the employeeManager control on the\u00a0Dashboard Screen references the managerName control on the employeeManagerScreen. There is also another control referencing the employeeDetailsScreen.<\/p>\n

\"\"<\/p>\n

These cross-screen control references caused both the employeeManagerScreen and the employeeDetailsScreen to load when the “Dashboard Screen” was first navigated to and performance would have been impacted.<\/p>\n

\u00a0<\/p>\n

What\u2019s next?<\/h1>\n