Debug power apps feature enabled

Debug Power Apps better with Monitor

Quite a while ago in 2018 I wrote about how to debug Power Apps. Then we still had to go through development steps just to understand what was happening in your app.

Available tools

Together with the Power Apps test tools it is becoming easier and better to debug your apps.

In this post I will go through the told to debug Power Apps. note that this feature is still in Preview, therefore you should be careful using this. But there is not a real reason why you can’t use this in your development environment.

Enabling the Debug Power Apps feature

To enable Debugging in Power Apps outside Power Apps studio you will need to enable the Debug published app experimental feature as shown below.

Experimental preview Debug Power Apps feature

If you don’t need to debug apps outside studio then you can leave this feature disabled.

Monitor your Power apps

Monitor feature in Power Apps

Then click on the open monitor and you will get the following blank screen opened in a new tab.

Debug Power Apps better with Monitor 1

You can now wait forever but nothing will happen until you run your app.

Example app

I created an example app that lists the number 1 to 10 in a gallery.

Debug Power Apps better with Monitor 2

I also have a timer control that shuffles the numbers using the Shuffle function every second. I will use this app to generate some actions that I can debug.

As soon as I run the app and my timer starts, the Power Apps monitor will pick up the code running in my timer. time to debug power apps.

Debug Power Apps better with Monitor 3

The Monitor UI

Now that we are ready to debug Power Apps and I click on any of the lines in the monitor the screen it will split into 2 sections.

Debug Power Apps better with Monitor 4

The Left hand side will show the following information about each line.

  • The Time
  • Category
  • Operation
  • Datasource
  • Control
  • Property,
  • Response size
  • Data

The right hand side will give further details.

Debug Power Apps better with Monitor 5

And the Formula used.

Debug Power Apps better with Monitor 6

And sometimes details on a request and its response.

Verbose debugging

If that is all not enough yet, you can also enable verbose debugging by selecting the verbose option just below the purple bar.

Debug Power Apps better with Monitor 7

This verbose option will include the Telemetry lines showing details on http requests being sent.

Calling flows from Power Apps

Debug Power Apps better with Monitor 8

This is where we can see the Request and the response.

My request is showing what was sent to Flow.

  "url": "",
  "method": "POST",
  "headers": {
    "x-ms-user-agent": "PowerApps/3.20054.18 (Web AuthoringTool; AppName=<NonCloudApp>)",
    "x-ms-client-session-id": "7969eab7-a666-4936-8001-055b3d9116a0",
    "x-ms-client-request-id": "00f351ef-f6b5-47fe-9ce9-99c1a318e1d7",
    "Accept-Language": "en-US",
    "Accept": "*/*",
    "Cache-Control": "no-cache, no-store",
    "x-ms-request-method": "POST",
    "x-ms-request-url": "/apim/logicflows/541d13027a264e208ef13196c187948e-4da32f4be74db047/triggers/manual/run?api-version=2015-02-01-preview"
  "body": ""

And the response is

  "duration": 421.51,
  "size": 404,
  "status": 502,
  "headers": {
    "Cache-Control": "no-cache",
    "Content-Length": 404,
    "Content-Type": "application/json",
    "Date": "Thu, 04 Jun 2020 16:08:09 GMT",
    "expires": -1,
    "pragma": "no-cache",
    "strict-transport-security": "max-age=31536000; includeSubDomains",
    "timing-allow-origin": "*",
    "x-ms-apihub-cached-response": true,
    "x-ms-client-tracking-id": "08586103199957470005347125871CU14",
    "x-ms-correlation-id": "5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-execution-location": "uksouth",
    "x-ms-failure-cause": "trigger",
    "x-ms-ratelimit-burst-remaining-workflow-writes": 6427,
    "x-ms-ratelimit-remaining-workflow-download-contentsize": 460174336,
    "x-ms-ratelimit-time-remaining-directapirequests": 42856814,
    "x-ms-request-id": "uksouth:5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-tracking-id": "5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-trigger-history-name": "08586103199957470005347125871CU14",
    "x-ms-workflow-id": "56e87932a910438bb9b03e2f6a45c0e6",
    "x-ms-workflow-name": "541d1302-7a26-4e20-8ef1-3196c187948e",
    "x-ms-workflow-run-id": "08586103199957470005347125871CU14",
    "x-ms-workflow-system-id": "/locations/uksouth/scaleunits/prod-25/workflows/56e87932a910438bb9b03e2f6a45c0e6",
    "x-ms-workflow-version": "08586115540418771010",
    "x-ms-client-request-id": "dff23d9b-5a1e-4818-8b14-253d08a3f8cd"
  "body": {
    "error": {
      "code": 502,
      "source": "",
      "clientRequestId": "dff23d9b-5a1e-4818-8b14-253d08a3f8cd",
      "message": "BadGateway",
      "innerError": {
        "error": {
          "code": "NoResponse",
          "message": "The server did not received a response from an upstream server. Request tracking id '08586103199957470005347125871CU14'."

Ok, now we have something to get started with.

Then after I fixed my flow issue I found a flow call that returned the 200 code rather than the 502 code that I initially received.

Debug Power Apps better with Monitor 9

Being able to get under the hood of the no code platform can be so important to speed up development.

Add your own tracing

Ok, now you’ve got your code reporting all sorts of debug to your monitor tools. But what if you want more specific information in your logs that isn’t reported by any of your code.

e.g. you want to know who is logged in.

So I added a button to report the user’s name

Debug Power Apps better with Monitor 10

And my report comes back.

Debug Power Apps better with Monitor 11

Let’s zoom in on that a bit

Debug Power Apps better with Monitor 12

You can see the severity and the Name property that I created and the Message.

Trace function

What can we do with the trace function?

Looking at the syntax description:

Trace(message, trace_severity, custom_record )

  • Message – Required. The information to be traced. In tests, this creates a record in the Traces table in the TestCaseResult record.
  • Trace_severity – Optional. The severity level of the Trace recorded in Application Insights. Options are TraceSeverity.Information, TraceSeverity.Warning or TraceSeverity.Error.
  • custom_record – Optional. A record containing custom data that will be recorded in Application Insights.

The message parameter is quite easy. This will appear in your monitoring tool. The trace severity is harder. Earlier I guessed that Error would have been an option. What other severity levels are there?

Currently you can use:

  • Information
  • Warning
  • Error

Other than in the details of a line in the monitoring tool you can’t see this anywhere yet.

Get Help

So what happens if you developed a Power app and you need some help? You can now send an invite to a colleague to help you debug your app.

Just click on the Invite button and supply the details of the colleague and they can help you debug your app.

Debug Power Apps better with Monitor 13

That is as easy as it can get.

Your experiences

Have you tried the debugger yet? Have you found any unclear error message? Do you need any help then please leave a comment below.

8 thoughts on “Debug Power Apps better with Monitor

  1. Do you know if this works on SharePoint forms customised with PowerApps? In my case, the monitor launches and “Connected” appears, but no interactions with the form appear in the monitor.

  2. Hello Pieter, I’m only trying to monitor events myself, not invite any other users. No events appear for customised SharePoint forms. I suspect that it doesn’t work for them (but I can’t yet find any documentation to that effect).

    (My replies to this topic don’t appear to be threading correctly – apologies.)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: