How to Monitor Azure Logic Apps Run Failures: Step-by-Step Guide

Azure Logic Apps orchestrate critical business workflows like payment processing, data sync, API integrations. When a workflow fails, the impact cascades: transactions drop, data goes stale, SLAs breach. Most teams discover Logic App failures hours after they happen, relying on customer complaints or manual checks.

This guide walks through setting up real time monitoring for Azure Logic Apps run failures using native Azure tools, diagnostic logs, and external monitoring platforms. You will learn how to track run history, configure failure alerts, diagnose root causes with trace data, and automate resubmission of failed runs.

Prerequisites

Before starting, ensure you have:

• An active Azure subscription with Logic Apps deployed
• Azure CLI installed and authenticated (az login)
• Owner or Contributor role on the Logic App resource group
• Access to Azure Monitor and Log Analytics workspace
• Basic familiarity with Azure portal navigation
• Optional: Access to a monitoring platform like CubeAPM, Turbo360, or Datadog

Step 1: Review Logic App Run History in Azure Portal

Every Logic App execution creates a run record containing status, inputs, outputs, and action results. The run history is the first place to check when failures occur.

1. Navigate to the Azure portal and open your Logic App
2. In the left sidebar, select Overview
3. Scroll to the Runs history section — this displays all recent runs with status indicators (Succeeded, Failed, Cancelled, Running)
4. Click on a failed run to drill into individual action outcomes

Each action in the run displays its own status. A failed run may show:

• Failed actions — the step where execution stopped
• Skipped actions — steps that did not execute because a prior condition was not met
• Timed out actions — steps that exceeded the default 2 minute timeout (configurable up to P1D via operationOptions)

What the run history does not tell you: Run history shows what failed but not always why. For recurring failures or high volume workflows, manually checking the portal is not scalable. This is where diagnostic logs and alerting become essential.

Step 2: Enable Diagnostic Logs and Send to Log Analytics

Diagnostic logs capture detailed execution metadata beyond what run history shows including trigger conditions, action retries, timeout reasons, and HTTP response bodies from failed external calls.

To enable diagnostic logs:

1. In the Azure portal, open your Logic App
2. Navigate to Monitoring → Diagnostic settings
3. Click Add diagnostic setting
4. Give it a name (e.g., LogicAppFailureLogs)
5. Under Logs, select:

• WorkflowRuntime — covers all workflow execution events
• WorkflowActivity — tracks individual action outcomes

1. Under Destination details, choose Send to Log Analytics workspace
2. Select your existing Log Analytics workspace or create a new one
3. Click Save

Logs begin flowing to the workspace within 5 minutes. You can now query them using KQL (Kusto Query Language).

Sample KQL query to find all failed runs in the last 24 hours:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where Category == "WorkflowRuntime"
| where status_s == "Failed"
| where TimeGenerated > ago(24h)
| project TimeGenerated, resource_workflowName_s, status_s, error_message_s
| order by TimeGenerated desc

This query surfaces:

• The exact time each failure occurred
• Which workflow failed
• The error message returned by the failed action

Why this matters: Azure Monitor’s default retention is 30 days. If you need longer retention for compliance or post-mortem analysis, infrastructure monitoring tools often provide extended log storage with no additional indexing cost.

Step 3: Configure Azure Monitor Alert Rules for Run Failures

Azure Monitor can detect Logic App failures and trigger alerts to Slack, email, or incident management platforms. Alert rules are condition based checks that fire when a metric or log query matches a threshold.

To create an alert rule for Logic App failures:

1. In the Azure portal, navigate to Monitor → Alerts → Create → Alert rule
2. Under Scope, select your Logic App resource
3. Under Condition, choose Add condition → Custom log search
4. Paste the KQL query from Step 2 (or modify it to match your failure criteria)
5. Set Threshold value to 1 — this fires the alert if any failed run is detected
6. Under Actions, create an action group or select an existing one to route the alert (email, SMS, webhook, Azure Function)
7. Name the alert rule (e.g., LogicApp-FailureAlert) and click Create alert rule

Sample alert query that fires only for repeated failures (3+ in 10 minutes):

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where Category == "WorkflowRuntime"
| where status_s == "Failed"
| where TimeGenerated > ago(10m)
| summarize FailureCount = count() by resource_workflowName_s
| where FailureCount >= 3

This reduces alert noise by ignoring single transient failures and only notifying when a pattern emerges.

Cost consideration: Azure Monitor alerts are billed per alert rule evaluated. Standard pricing is $0.10 per rule per month. For teams monitoring multiple Logic Apps, grouping alert rules by resource group or using a shared Log Analytics workspace reduces cost.

Step 4: Use Application Insights for Distributed Tracing Across Logic Apps and Dependencies

When a Logic App calls an external API, database, or another Azure service, the failure may originate downstream — not in the Logic App itself. Application Insights provides distributed tracing that links Logic App runs to their upstream and downstream dependencies.

To connect Application Insights to your Logic App:

1. Create an Application Insights resource in the Azure portal (if you do not have one)
2. Open your Logic App → Settings → Application Insights
3. Click Turn on Application Insights
4. Select your Application Insights instance and click Apply

Once enabled, Application Insights captures:

• End to end transaction traces across Logic App actions and external calls
• Dependency latency for HTTP requests, database queries, and service bus operations
• Exception stack traces when an action throws an error

Sample KQL query in Application Insights to find slow external API calls:

dependencies
| where type == "Http"
| where success == false
| where timestamp > ago(1h)
| project timestamp, target, resultCode, duration
| order by duration desc

This surfaces which external services are causing Logic App failures and how long they took before timing out.

Why distributed tracing matters: Logic Apps often sit in the middle of multi-step workflows. A failure logged as “HTTP 500” in run history could be caused by a downstream service throttling requests, a misconfigured API key, or a transient network issue. Application Insights traces the full request path so you can isolate the root cause without guessing.

Step 5: Automate Resubmission of Failed Logic App Runs

Some Logic App failures are transient — an external API was temporarily unavailable, a database connection timed out, a rate limit was hit. Resubmitting these runs manually works for small volumes, but does not scale.

Two approaches to automate resubmission:

Option 1: Use Azure Automation with PowerShell

Create an Azure Automation runbook that queries failed runs via the Azure Management API and resubmits them.

Sample PowerShell script to resubmit all failed runs in the last hour:

$resourceGroup = "your-resource-group"
$logicAppName = "your-logic-app"
$subscriptionId = "your-subscription-id"
Connect-AzAccount
$runs = Get-AzLogicAppRunHistory -ResourceGroupName $resourceGroup -Name $logicAppName `
| Where-Object { $_.Status -eq "Failed" -and $_.StartTime -gt (Get-Date).AddHours(-1) }
foreach ($run in $runs) {
    Invoke-AzResourceAction -ResourceGroupName $resourceGroup -ResourceType "Microsoft.Logic/workflows" `
    -ResourceName $logicAppName -Action "resubmit" -Parameters @{ runName = $run.Name } -Force
}

Schedule this runbook to execute every hour using an Azure Automation schedule.

Option 2: Use Turbo360 Business Applications for Centralized Resubmission

Turbo360 provides Logic App specific monitoring with bulk resubmission, filtering by error type, and automatic tagging of resubmitted runs. It groups Logic Apps into Business Applications — logical containers for workflows that belong to the same business process.

To set up automated resubmission in Turbo360:

1. Create a Business Application and add your Logic Apps
2. Apply a monitoring profile that tracks run failures
3. Configure an automated task: Resubmit failed runs with filters for:

• Error reason (e.g., exclude 4xx client errors, resubmit 5xx server errors)
• Trigger type (resubmit only runs from specific triggers)
• Already resubmitted runs (include or exclude)

1. Attach the task to the monitor rule so it executes automatically when violations are detected

This approach eliminates the need to write custom scripts and provides visibility into which runs were resubmitted and when.

Step 6: Monitor Logic App Performance Metrics in Real Time

Beyond failure detection, tracking performance metrics helps catch issues before they cause failures. Azure Monitor provides built-in metrics for Logic Apps:

• Runs Started — total executions per minute
• Runs Completed — successful executions
• Runs Failed — failed executions
• Run Duration — how long each run took from trigger to completion
• Action Latency — time spent in individual actions

To view these metrics:

1. Open your Logic App in the Azure portal
2. Navigate to Monitoring → Metrics
3. Select a metric (e.g., Runs Failed)
4. Set the time range and aggregation (e.g., Sum over 5 minutes)
5. Click Add metric to overlay additional signals (e.g., Run Duration)

Sample alert rule to detect abnormal run duration:

Create an alert that fires when average run duration exceeds 5 minutes:

1. Navigate to Monitor → Alerts → Create alert rule
2. Select your Logic App as the scope
3. Add condition: Run Duration → Average → Greater than 300 seconds
4. Set evaluation frequency to 5 minutes
5. Attach an action group

This catches performance degradation before it leads to timeouts and failures.

Step 7: Centralize Logic App Monitoring with External Platforms

Azure Monitor works well for single Logic Apps or small deployments. At scale — 10+ Logic Apps across multiple resource groups or subscriptions — native tools become operationally heavy. Every Logic App needs its own diagnostic setting, alert rule, and metric configuration.

External monitoring platforms aggregate Logic App telemetry alongside other Azure resources, application traces, and infrastructure metrics. This provides:

• Unified dashboards showing Logic App health across environments
• Correlation between Logic App failures and upstream dependencies (APIs, databases, Event Grid)
• Longer retention without cold storage fees
• Custom alerting logic that groups failures by business impact, not just resource ID

Monitoring Logic Apps with CubeAPM

CubeAPM runs inside your Azure VPC and ingests Logic App diagnostic logs, Application Insights traces, and Azure Monitor metrics via OpenTelemetry. It provides:

• Unified view of Logic App runs, action outcomes, and dependency latency in one dashboard
• Distributed tracing that links Logic App failures to upstream API calls or downstream database queries
• Alerting on custom conditions (e.g., “alert if payment-processing Logic App fails 3 times in 10 minutes”)
• Unlimited log retention at $0.15/GB — no separate indexing or query fees

How to connect Logic Apps to CubeAPM:

1. Enable diagnostic logs on your Logic Apps (Step 2 above)
2. Configure Log Analytics workspace to forward logs to CubeAPM via OpenTelemetry Collector
3. Deploy the CubeAPM agent in your Azure VPC using the provided Helm chart or Docker Compose setup
4. View Logic App run data in CubeAPM’s APM dashboard under the Workflows section

Pricing context: For a team running 10 Logic Apps generating 500GB of logs and traces per month, Azure Monitor costs approximately $150/month (Log Analytics ingestion at $0.30/GB). Forwarding the same data to CubeAPM costs $75/month ($0.15/GB) with no additional query or retention fees.

CubeAPM is included as one of the tools in this comparison. We have disclosed this transparently so you can weigh it accordingly. Pricing and features are sourced from CubeAPM’s official pricing page.

Troubleshooting Common Issues

Logic App run history not showing recent runs

Cause: Azure portal run history has a default retention of 90 days and displays the most recent 30 runs by default. Older runs are not deleted but require expanding the time range filter.

Fix: In the run history view, adjust the date filter to include earlier runs or query diagnostic logs in Log Analytics.

Alert rule fires but no notification is received

Cause: The action group attached to the alert rule is misconfigured or the destination (email, webhook) is unreachable.

Fix: Test the action group manually: Open the action group in the Azure portal → click Test → select a sample alert payload. Verify that the email or webhook endpoint receives the test.

Failed runs cannot be resubmitted via API

Cause: The Azure Management API requires specific permissions to resubmit runs. If the service principal or user account lacks Microsoft.Logic/workflows/triggers/run/action permissions, resubmission fails.

Fix: Assign the Logic App Contributor role to the identity making the API call.

Diagnostic logs are missing action-level details

Cause: Only the WorkflowRuntime log category is enabled. Action-level details require enabling WorkflowActivity as well.

Fix: Go back to Diagnostic settings and enable both WorkflowRuntime and WorkflowActivity.

Conclusion

Monitoring Azure Logic Apps run failures requires more than checking the portal after something breaks. The combination of diagnostic logs, real time alerts, distributed tracing, and automated resubmission turns reactive firefighting into proactive issue detection.

For teams managing a handful of Logic Apps, Azure Monitor and Log Analytics provide sufficient coverage. As complexity grows — more workflows, more dependencies, more environments — external platforms like CubeAPM, Turbo360, or Azure monitoring tools centralize telemetry and reduce alert fatigue. The key is to set up monitoring early, test alert rules under real failure conditions, and document runbook steps so any team member can respond to incidents without escalation.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions