Azure

How to debug Azure Logic Apps workflow failures and retry behavior

Understanding Logic Apps Workflow Failures

Azure Logic Apps orchestrates business processes by chaining triggers and actions into automated workflows. When a workflow fails, the impact can range from a missed notification to a broken business process affecting customers. Effective debugging requires understanding how Logic Apps tracks execution history, how retry policies work, and how to build error handling directly into your workflow design.

This guide covers the complete debugging lifecycle for Logic Apps, from identifying failures in run history to configuring retry policies, implementing structured error handling with scopes, and setting up proactive monitoring alerts.

How Logic Apps Tracks Workflow Execution

Every Logic Apps workflow run generates a detailed execution record that captures the status, inputs, outputs, and timing of every trigger and action. Understanding these statuses is the first step in debugging.

Run Status Meaning Common Cause
Succeeded All actions completed successfully Normal operation
Failed One or more actions failed and no error handler caught the failure API errors, timeout, bad data
Cancelled Workflow was manually cancelled or cancelled by a parent workflow User intervention
Aborted Trigger succeeded but the run was aborted before completion Concurrency control, system issues
TimedOut Workflow exceeded its maximum duration Long-running operations without async patterns
Running Workflow is currently executing In-progress execution
Waiting Workflow is waiting for an event or approval Manual approval steps, webhook callbacks
Skipped Action was skipped due to run-after configuration Predecessor condition not met

A special status worth noting is Succeeded with retries, which indicates an action initially failed but succeeded after the retry policy kicked in. This is not a failure, but it signals transient issues that may warrant investigation if they happen frequently.

Debugging Workflow Failures Step by Step

Step 1: Check Trigger History

The trigger is the entry point of every workflow. If the trigger itself fails, the workflow never runs.

  1. Navigate to your Logic App in the Azure portal.
  2. Click Overview → Trigger history.
  3. Review the status column for any Failed or Skipped triggers.
  4. Click a failed trigger to inspect its Inputs and Outputs.

Common trigger failures include expired connections (OAuth tokens), polling endpoint unavailability, and malformed trigger conditions. For HTTP-based triggers, check the response status code and body in the outputs.

Step 2: Inspect Run History

  1. Click Overview → Runs history.
  2. Filter by status to show only Failed runs.
  3. Click a failed run to open the run detail view.
  4. The workflow designer shows each action with a status indicator. Red actions indicate failures.
  5. Click the failed action to expand its Inputs, Outputs, and error details.

The error output typically includes an HTTP status code, error message, and sometimes a correlation ID that you can use for cross-referencing with downstream service logs.

Step 3: Get the Correlation ID

Each workflow run has a unique Correlation ID available in the Run details panel. This ID is invaluable for tracing requests through multiple systems. When contacting Microsoft support or correlating with Application Insights telemetry, always provide this ID.

Step 4: Resubmit Failed Runs

Logic Apps allows you to replay failed runs without manually recreating the trigger event:

  • Resubmit entire workflow — In Runs history, select the failed run and click Resubmit. This replays the original trigger data through the entire workflow.
  • Rerun from a specific action — Select the action where you want to restart and click Submit from this action. This is available for sequential workflows with up to 40 actions.

Understanding Retry Policies

Logic Apps includes built-in retry behavior for transient failures. The retry policy determines how many times and how frequently an action retries after receiving an HTTP 408 (Request Timeout), 429 (Too Many Requests), or 5xx (Server Error) response.

Retry Policy Types

Policy Behavior Best For
Default Up to 4 retries with exponential backoff (7.5s intervals, capped at 5-45s) Most scenarios
None No retries — fail immediately Non-idempotent operations, custom error handling
Fixed interval Constant wait time between retries APIs with fixed rate limit windows
Exponential interval Increasing wait time from an exponentially growing range Services with progressive backoff requirements

Configuring Retry Policies

Retry policies are configured per action in the workflow definition. Switch to Code view in the designer to modify them directly.

{
  "actions": {
    "Call_External_API": {
      "type": "Http",
      "inputs": {
        "method": "POST",
        "uri": "https://api.contoso.com/process",
        "body": "@triggerBody()"
      },
      "retryPolicy": {
        "type": "exponential",
        "count": 4,
        "interval": "PT10S",
        "minimumInterval": "PT5S",
        "maximumInterval": "PT1H"
      }
    }
  }
}

For a fixed interval policy:

"retryPolicy": {
  "type": "fixed",
  "count": 3,
  "interval": "PT30S"
}

To disable retries entirely:

"retryPolicy": {
  "type": "none"
}

Retry Count Limits

The maximum retry count is 90. The interval uses ISO 8601 duration format (e.g., PT10S for 10 seconds, PT5M for 5 minutes, PT1H for 1 hour). For exponential backoff, the actual wait time is randomly selected from the range between minimumInterval and the exponentially calculated upper bound, capped at maximumInterval.

Structured Error Handling with Scopes

For production workflows, relying solely on retry policies is insufficient. You need structured error handling that catches failures, logs diagnostic information, and takes compensating actions.

The Scope Pattern

Logic Apps supports Scope actions that group related actions together, similar to try-catch blocks in programming. When any action inside a scope fails, you can configure downstream actions to run specifically on that failure.

  1. Add a Scope action and place your business logic actions inside it (this is your “try” block).
  2. Add a second Scope after the first one for error handling (this is your “catch” block).
  3. Configure the catch scope’s Run After settings to run on Failed, Skipped, and TimedOut statuses of the try scope.

Configuring Run After

In the designer, click the three dots (…) on an action and select Configure run after. You can specify which predecessor statuses trigger this action:

  • Is successful — Normal happy-path execution
  • Has failed — Predecessor action failed
  • Is skipped — Predecessor was skipped
  • Has timed out — Predecessor exceeded its timeout

In code view, this appears as:

"Error_Handling_Scope": {
  "type": "Scope",
  "actions": {
    "Send_Error_Notification": {
      "type": "ApiConnection",
      "inputs": {
        "host": { "connection": { "name": "office365" } },
        "method": "post",
        "path": "/v2/Mail",
        "body": {
          "To": "ops-team@contoso.com",
          "Subject": "Logic App Failure: @{workflow().name}",
          "Body": "Run ID: @{workflow().run.name}\nError: @{result('Business_Logic_Scope')}"
        }
      }
    }
  },
  "runAfter": {
    "Business_Logic_Scope": ["Failed", "Skipped", "TimedOut"]
  }
}

Extracting Error Details from Scopes

Use the result() function to get the execution results of all actions within a scope, then filter for failures:

{
  "Filter_Failed_Actions": {
    "type": "Query",
    "inputs": {
      "from": "@result('Business_Logic_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
    },
    "runAfter": {
      "Business_Logic_Scope": ["Failed"]
    }
  }
}

The filtered array contains the name, status, inputs, outputs, and error details of each failed action — all the information you need for diagnostic logging.

Advanced Debugging with Webhook Tester

When you need to inspect the exact data flowing through a workflow at a specific point, add a temporary HTTP POST action that sends data to an external webhook tester service:

  1. Go to webhook.site and copy the unique URL.
  2. Add an HTTP action at the point in your workflow where you want to inspect data.
  3. Set the method to POST and the URI to your webhook.site URL.
  4. Set the body to the expression or variable you want to inspect.
  5. Run the workflow and check webhook.site for the captured data.
  6. Remove the debug action after troubleshooting.

Setting Up Monitoring Alerts

Proactive alerting ensures you know about failures before users report them.

Azure Monitor Alert for Failed Triggers

  1. Navigate to your Logic App → Monitoring → Alerts → Create alert rule.
  2. Select signal: Triggers Failed.
  3. Configure condition: Threshold greater than or equal to 1.
  4. Set evaluation: Check every 1 minute, lookback period 5 minutes.
  5. Attach an action group for email, SMS, or Teams notification.

Log Analytics Queries for Failure Analysis

If you send Logic Apps diagnostics to a Log Analytics workspace, use KQL to analyze failure patterns:

// Failed runs in the last 24 hours with error details
AzureDiagnostics
| where ResourceType == "WORKFLOWS"
| where Category == "WorkflowRuntime"
| where status_s == "Failed"
| where TimeGenerated > ago(24h)
| project TimeGenerated, resource_workflowName_s, resource_actionName_s, error_code_s, error_message_s
| order by TimeGenerated desc

// Retry pattern analysis
AzureDiagnostics
| where ResourceType == "WORKFLOWS"
| where Category == "WorkflowRuntime"
| where status_s == "Succeeded" and retryHistory_s != ""
| summarize RetryCount = count() by resource_workflowName_s, resource_actionName_s, bin(TimeGenerated, 1h)
| order by RetryCount desc

Consumption vs. Standard Workflow Differences

Debugging approaches differ slightly between Consumption (multi-tenant) and Standard (single-tenant) Logic Apps:

Aspect Consumption Standard
Run history Azure portal only Azure portal + local development tools
Local debugging Not supported VS Code with Azurite for local testing
Storage dependency Managed by Azure Requires accessible storage account — firewall rules can cause failures
Performance predictability Shared infrastructure, variable Dedicated compute, more predictable
Diagnostics Run history + Azure Monitor Run history + Azure Monitor + App Insights integration

For Standard workflows, a common failure mode is storage account inaccessibility. If the workflow’s host storage account has firewall rules, private endpoints, or access restrictions, the runtime cannot persist state and the workflow fails. Use nslookup and psping to verify storage connectivity from the Standard Logic App’s infrastructure.

Common Pitfalls and Best Practices

  • Action timeout is 2 minutes — Individual HTTP actions have a fixed 2-minute timeout. For long-running operations, use the asynchronous polling pattern where the target API returns a 202 with a location header for status polling.
  • Unicode in names — Trigger, action, or run names containing Unicode characters can cause exported diagnostic logs to be dropped silently. Use ASCII-only names.
  • Connector authentication expiry — API connections (Office 365, SQL, etc.) use OAuth tokens that expire. Set up Azure Monitor alerts on failed triggers to catch expired connections quickly.
  • Idempotency for retries — When retries are enabled, ensure downstream operations are idempotent. If an HTTP POST creates a record, a retry may create a duplicate. Use conditional checks or unique identifiers to prevent duplicate processing.
  • Concurrency limits — The default concurrency for triggers is unlimited, which can overwhelm downstream services. Set a degree of parallelism on the trigger to limit concurrent runs.
  • Split-on for batch triggers — When a trigger returns an array, the SplitOn property creates individual runs for each item. This can rapidly consume your action quota if the array is large.

Conclusion

Debugging Azure Logic Apps workflow failures is a systematic process: start with trigger history to confirm the workflow was invoked correctly, then inspect run history to identify the failing action and its error details. Configure retry policies that match each downstream service’s resilience characteristics — exponential backoff for general APIs, fixed intervals for rate-limited services, and no retries for non-idempotent operations. Build structured error handling with scopes and run-after configurations to catch failures gracefully, log diagnostic information, and take compensating actions. Finally, instrument your workflows with Azure Monitor alerts and Log Analytics diagnostics to detect and investigate failures before they impact your business.

For more details, refer to the official documentation: What is Azure Logic Apps?, Connectors overview for Azure Logic Apps.

Leave a Reply