title | description | services | ms.suite | ms.reviewer | ms.topic | ms.date |
---|---|---|---|---|---|---|
Monitor status, view history, and set up alerts |
Troubleshoot logic apps by checking run status, reviewing trigger history, and enabling alerts in Azure Logic Apps |
logic-apps |
integration |
divswa, logicappspm |
article |
05/04/2020 |
After you create and run a logic app, you can check that logic app's run status, runs history, trigger history, and performance. To get notifications about failures or other possible problems, set up alerts. For example, you can create an alert that detects "when more than five runs fail in an hour."
For real-time event monitoring and richer debugging, set up diagnostics logging for your logic app by using Azure Monitor logs. This Azure service helps you monitor your cloud and on-premises environments so that you can more easily maintain their availability and performance. You can then find and view events, such as trigger events, run events, and action events. By storing this information in Azure Monitor logs, you can create log queries that help you find and analyze this information. You can also use this diagnostic data with other Azure services, such as Azure Storage and Azure Event Hubs. For more information, see Monitor logic apps by using Azure Monitor.
Note
If your logic apps run in an integration service environment (ISE) that was created to use an internal access endpoint, you can view and access inputs and outputs from logic app's runs history only from inside your virtual network. Make sure that you have network connectivity between the private endpoints and the computer from where you want to access runs history. For example, your client computer can exist inside the ISE's virtual network or inside a virtual network that's connected to the ISE's virtual network, for example, through peering or a virtual private network. For more information, see ISE endpoint access.
Each time that the trigger fires for an item or event, the Logic Apps engine creates and runs a separate workflow instance for each item or event. By default, each workflow instance runs in parallel so that no workflow has to wait before starting a run. You can review what happened during that run, including the status for each step in the workflow plus the inputs and outputs for each step.
-
In the Azure portal, find and open your logic app in the Logic App Designer.
To find your logic app , in the main Azure search box, enter
logic apps
, and then select Logic Apps.The Azure portal shows all the logic apps that are associated with your Azure subscriptions. You can filter this list based on name, subscription, resource group, location, and so on.
-
Select your logic app, and then select Overview.
On the overview pane, under Runs history, all the past, current, and any waiting runs for your logic app appear. If the list shows many runs, and you can't find the entry that you want, try filtering the list. If you don't find the data that you expect, try selecting Refresh on the toolbar.
Here are the possible statuses for a logic app run:
Status Description Cancelled The workflow was running but received a cancel request Failed At least one action failed, and no later actions in the workflow were set up to handle the failure Running The workflow is currently running. This status can also appear for throttled workflows or due to the current pricing plan. For more information, see the action limits on the pricing page. If you set up diagnostics logging, you can get information about any throttle events that happen.
Succeeded All actions succeeded. Note: If any failures happened in a specific action, a later action in the workflow handled that failure.
Waiting The workflow hasn't started or is paused, for example, due to an earlier workflow that's still running. -
To review the steps and other information for a specific run, under Runs history, select that run.
The Logic app run pane shows each step in the selected run, each step's run status, and the time taken for each step to run, for example:
To view this information in list form, on the Logic app run toolbar, select Run Details.
The Run Details view shows each step, their status, and other information.
For example, you can get the run's Correlation ID property, which you might need when you use the REST API for Logic Apps.
-
To get more information about a specific step, select either option:
-
In the Logic app run pane select the step so that the shape expands. You can now view information such as inputs, outputs, and any errors that happened in that step, for example:
-
In the Logic app run details pane, select the step that you want.
You can now view information such as inputs and outputs for that step, for example:
[!NOTE] All runtime details and events are encrypted within the Logic Apps service. They are decrypted only when a user requests to view that data. You can hide inputs and outputs in run history or control user access to this information by using Azure role-based access control (Azure RBAC).
-
Each logic app run starts with a trigger. The trigger history lists all the trigger attempts that your logic app made and information about the inputs and outputs for each trigger attempt.
-
In the Azure portal, find and open your logic app in the Logic App Designer.
To find your logic app , in the main Azure search box, enter
logic apps
, and then select Logic Apps.The Azure portal shows all the logic apps that are associated with your Azure subscriptions. You can filter this list based on name, subscription, resource group, location, and so on.
-
Select your logic app, and then select Overview.
-
On your logic app's menu, select Overview. In the Summary section, under Evaluation, select See trigger history.
The trigger history pane shows all the trigger attempts that your logic app has made. Each time that the trigger fires for an item or event, the Logic Apps engine creates a separate logic app instance that runs the workflow. By default, each instance runs in parallel so that no workflow has to wait before starting a run. So if your logic app triggers on multiple items at the same time, a trigger entry with the same date and time appears for each item.
Here are the possible statuses for a trigger attempt:
Status Description Failed An error occurred. To review any generated error messages for a failed trigger, select that trigger attempt and choose Outputs. For example, you might find inputs that aren't valid. Skipped The trigger checked the endpoint but found no data. Succeeded The trigger checked the endpoint and found available data. Usually, a "Fired" status also appears alongside this status. If not, the trigger definition might have a condition or SplitOn
command that wasn't met.This status can apply to a manual trigger, recurrence trigger, or polling trigger. A trigger can run successfully, but the run itself might still fail when the actions generate unhandled errors.
[!TIP] You can recheck the trigger without waiting for the next recurrence. On the overview toolbar, select Run trigger, and select the trigger, which forces a check. Or, select Run on Logic Apps Designer toolbar.
-
To view information about a specific trigger attempt, on the trigger pane, select that trigger event. If the list shows many trigger attempts, and you can't find the entry that you want, try filtering the list. If you don't find the data that you expect, try selecting Refresh on the toolbar.
You can now review information about the selected trigger event, for example:
To get alerts based on specific metrics or exceeded thresholds for your logic app, set up alerts in Azure Monitor. Learn about metrics in Azure. To set up alerts without using Azure Monitor, follow these steps.
-
On your logic app menu, under Monitoring, select Alerts > New alert rule.
-
On the Create rule pane, under Resource, select your logic app, if not already selected. Under Condition, select Add so that you can define the condition that triggers the alert.
-
On the Configure signal logic pane, find and select the signal for which you want to get an alert. You can use the search box, or to sort the signals alphabetically, select the Signal name column header.
For example, if you want to send an alert when a trigger fails, follow these steps:
-
In the Signal name column, find and select the Triggers Failed signal.
-
On the information pane that opens for the selected signal, under Alert logic, set up your condition, for example:
-
For Operator, select Greater than or equal to.
-
For Aggregation type, select Count.
-
For Threshold value, enter
1
. -
Under Condition preview, confirm that your condition appears correct.
-
Under Evaluated based on, set up the interval and frequency for running the alert rule. For Aggregation granularity (Period), select the period for grouping the data. For Frequency of evaluation, select how often you want to check the condition.
-
When you're ready, select Done.
Here's the finished condition:
The Create rule page now shows the condition that you created and the cost for running that alert.
-
-
Specify a name, optional description, and severity level for your alert. Either leave the Enable rule upon creation setting turned on, or turn off until you're ready to enable the rule.
-
When you're done, select Create alert rule.
Tip
To run a logic app from an alert, you can include the request trigger in your workflow, which lets you perform tasks like these examples: