Azure Logic Apps Monitoring: How To Detect Automation Failures In Your SOC

In modern Security Operations Centers (SOCs), Azure Logic Apps have become the backbone of SOAR (Security Orchestration, Automation, and Response) workflows. From automated alert enrichment and threat intelligence lookups to ticket creation and endpoint isolation, Logic Apps quietly handle hundreds of critical tasks every day.

But what happens when they fail silently? A broken playbook can leave an alert unenriched, a phishing email unactioned, or an incident response step quietly skipped—with no one the wiser until the damage is done. In high-volume environments, even a small failure rate can compound into a significant operational gap.

This blog explores the Logic Apps monitoring options available in Azure, the practical limitations of conventional approaches, and a targeted monitoring workflow designed specifically for automation teams rather than the SOC incident queue.

Option 1: Alert Rules & Action Groups

Azure Monitor can create alert rules from Logic Apps metrics, such as failed runs, and use Action Groups to notify teams through email, SMS, webhooks, or downstream automation. This is useful for immediate alerting, but several limitations emerge when the requirement is a consolidated daily automation-health report:

Limited default context: A metric alert identifies the affected signal and resource, but engineers may still need to open the Azure Portal or run a log query to obtain the failed Run ID, action, error message, and ownership details.

Threshold design: A single count-based threshold can over-alert on transient failures or understate persistent low-volume problems across many workflows.

Failure-rate context: A workflow that runs 1,000 times and fails 10 times presents a different risk from one that runs 10 times and fails 10 times. Raw failure counts do not provide that denominator.

Digest requirements: Default notifications do not provide the cross-workflow, threaded daily digest used by the automation team. An additional workflow is needed to aggregate and format the results.

Routing requirements: Resource tags, ownership information, workflow criticality, and team-specific routing usually require enrichment logic beyond the default notification payload.

Option 2: Microsoft Sentinel Analytics Rules

Microsoft Sentinel scheduled analytics rules provide flexible KQL-based detection. However, using security analytics rules for routine automation-health reporting can create an operational ownership problem:

SOC queue pollution: Logic App failures are normally engineering or platform-health issues rather than security incidents. Creating Sentinel incidents for them can compete with genuine threats for analyst attention.

The wrong audience: SOC analysts may receive infrastructure failures they cannot remediate, while automation engineers receive the information indirectly.

Incident semantics: Sentinel rules are optimized for security detections, alert enrichment, entity mapping, and incident creation. A daily automation-health digest has a different operational purpose.

Additional lifecycle management: Rules, incident grouping, suppression, and closure behavior must be maintained even when the required outcome is simply an engineering notification.

Step 1 — Enable Diagnostic Logging on Logic Apps

The foundation of the solution is enabling Azure diagnostic settings on the Logic Apps that you want to monitor and sending their workflow runtime telemetry to a central Log Analytics workspace. This provides capabilities beyond simple failure counts:

• Centralized run telemetry: Workflow completion events include timestamps, workflow and Run IDs, status, and related diagnostic fields that can be queried with KQL.
• Action-level granularity: Action completion events can identify the failed step, error code, and error message when deeper investigation is needed.
• Retention and auditability: Log Analytics retention is controlled by the workspace policy and can support historical analysis, trend reporting, and audit requirements beyond the workflow’s default native run-history period.
• Cross-resource correlation: Failures can be correlated with identity, networking, API, connector, or other platform telemetry collected in the workspace.
• Flexible filtering: Resource IDs, environments, owners, criticality, and monitoring scope can be controlled through a consistent tagging convention rather than hard-coded workflow names.
• Centralized visibility: A single workspace can aggregate telemetry from multiple resource groups and subscriptions when the environment and access model permit it.

Step 2 — The Monitoring Logic App

Rather than creating security incidents, a dedicated monitoring Logic App runs on a schedule and sends a targeted report directly to the automation team’s Microsoft Teams channel.

The workflow operates as follows:

• Recurrence trigger: Runs daily at a configured time. Environments requiring faster detection can use an hourly schedule and retain the daily digest for trend reporting.
• Failure discovery query: Finds workflows with failed runs during the selected lookback period and returns a direct Azure Portal link for each workflow.
• Failure-rate summary query: Calculates total runs, failed runs, successful runs, and the failure-rate percentage for each workflow, then applies a configurable reporting threshold.
• Run-ID drill-down: Retrieves the failed Run IDs for every affected workflow. This compact reply remains useful even when the environment contains many workflows and failures.
• Critical-workflow detail: For workflows tagged Criticality=Critical, a separate query retrieves failed actions, timestamps, error codes, error messages, ownership information, and direct run links.
• Teams notification: Posts the failure-rate Adaptive Card separately, and creates a failure thread containing the workflow list, a Run-ID reply for all failures, and an additional detailed reply only when critical workflows failed.
• Conditional execution: If no failures are detected, the failure thread is not posted. If failures exist but none belong to critical workflows, the critical-details reply is skipped.

KQL — Failure Discovery Query

let Lookback = 24h;
AzureDiagnostics
| where TimeGenerated > ago(Lookback)
| where ResourceProvider =~ "MICROSOFT.LOGIC"
| where Category == "WorkflowRuntime"
| where OperationName == "Microsoft.Logic/workflows/workflowRunCompleted"
| where status_s == "Failed"
| extend
 WorkflowName = tostring(resource_workflowName_s),
 WorkflowId = tostring(workflowId_s)
| extend LogicAppUrl = strcat(
 "https://portal.azure.com/#resource",
 WorkflowId
)
| summarize arg_max(TimeGenerated, LogicAppUrl)
 by WorkflowId, WorkflowName
| project WorkflowName, WorkflowId, LogicAppUrl,
 LastFailure = TimeGenerated
| order by WorkflowName asc

In the implementation, the results are grouped by workflow before being posted to Teams. Carrying WorkflowId alongside WorkflowName avoids merging identically named workflows from different resource groups or subscriptions.

KQL — Failure-Rate Summary

let Lookback = 24h;
let MinimumFailures = 1;
let MinimumFailureRate = 1.0;
AzureDiagnostics
| where TimeGenerated > ago(Lookback)
| where ResourceProvider =~ "MICROSOFT.LOGIC"
| where Category == "WorkflowRuntime"
| where OperationName == "Microsoft.Logic/workflows/workflowRunCompleted"
| where status_s in ("Failed", "Succeeded")
| extend
 WorkflowName = tostring(resource_workflowName_s),
 WorkflowId = tostring(workflowId_s),
 RunId = tostring(resource_runId_s)
| summarize
 Total = dcount(RunId),
 Failed = dcountif(RunId, status_s == "Failed"),
 Succeeded = dcountif(RunId, status_s == "Succeeded")
 by WorkflowId, WorkflowName
| extend FailureRate = round(100.0 * Failed / Total, 1)
| where Failed >= MinimumFailures
| where FailureRate > MinimumFailureRate
| order by FailureRate desc

KQL — Critical Workflow Action Details

let Lookback = 24h;

let FailedRuns = AzureDiagnostics

| where TimeGenerated > ago(Lookback)

| where ResourceProvider =~ "MICROSOFT.LOGIC"

| where Category == "WorkflowRuntime"

| where OperationName == "Microsoft.Logic/workflows/workflowRunCompleted"

| where status_s == "Failed"

| extend Tags = parse_json(tostring(column_ifexists("tags_s", "{}")))

| extend Criticality = tolower(tostring(Tags.Criticality))

| where Criticality == "critical"

| extend CreatedBy = coalesce(

    tostring(Tags.Created_By),

    tostring(Tags.CreatedBy),

    tostring(Tags.Owner),

    "Unknown")

| project

    TimeGenerated,

    WorkflowName = tostring(resource_workflowName_s),

    WorkflowId = tostring(workflowId_s),

    RunId = tostring(resource_runId_s),

    RunErrorCode = tostring(code_s),

    RunErrorMessage = tostring(error_message_s),

    CreatedBy;

let FailedActions = AzureDiagnostics

| where TimeGenerated > ago(Lookback)

| where ResourceProvider =~ "MICROSOFT.LOGIC"

| where Category == "WorkflowRuntime"

| where OperationName == "Microsoft.Logic/workflows/workflowActionCompleted"

| where status_s == "Failed"

| project

    WorkflowId = tostring(workflowId_s),

    RunId = tostring(resource_runId_s),

    ActionName = tostring(resource_actionName_s),

    ActionErrorCode = tostring(code_s),

    ActionErrorMessage = tostring(error_message_s);

FailedRuns

| join kind=leftouter FailedActions on WorkflowId, RunId

| extend

    ActionName = coalesce(ActionName, "Run-level failure"),

    ErrorCode = coalesce(ActionErrorCode, RunErrorCode, "Unknown"),

    ErrorMessage = coalesce(

        ActionErrorMessage,

        RunErrorMessage,

        "No error message was recorded")

| project TimeGenerated, WorkflowName, WorkflowId, RunId,

    ActionName, ErrorCode, ErrorMessage, CreatedBy

| order by WorkflowName asc, TimeGenerated desc

This two-stage pattern is deliberate: action-level failures are expanded only after the workflow run itself is confirmed as Failed. Handled action failures inside catch scopes therefore do not create critical detail unless the overall run also fails.

This solution is particularly useful in environments with mature Logic App error-handling patterns. A workflow can use a catch scope or run-after configuration to handle an expected action failure and still complete successfully. Reporting every failed action in isolation would generate noise for conditions the workflow was designed to manage.

The monitoring workflow first evaluates the final run status. All failed runs are made visible through a compact Run-ID reply, while richer action and error details are reserved for workflows explicitly marked as critical. This balances visibility with message volume and keeps high-priority failures actionable.

Managed API connections are critical dependencies for many Consumption Logic Apps. Authentication failures, revoked consent, expired credentials, or service-side problems can prevent workflow actions from completing even when the workflow definition itself has not changed.

Azure Resource Graph provides a centralized inventory view of Microsoft.Web/connections resources and their current reported status. This complements run-failure monitoring; it should not be confused with monitoring downstream API response codes or application-level API availability.

let ApiConnections = resources

| where type =~ "microsoft.web/connections"

| extend ConnectionStatuses = todynamic(properties.statuses)

| mv-expand ConnectionStatusRecord = ConnectionStatuses

| extend

    ConnectionId = tolower(id),

    ConnectionName = name,

    DisplayName = tostring(properties.displayName),

    ConnectionStatus = tostring(ConnectionStatusRecord.status),

    StatusError = tostring(ConnectionStatusRecord.error.message)

| where ConnectionStatus =~ "Error"

| project ConnectionId, ConnectionName, DisplayName,

    ConnectionResourceGroup = resourceGroup,

    ConnectionStatus, StatusError;

let WorkflowConnections = resources

| where type =~ "microsoft.logic/workflows"

| extend Connections = properties.parameters["$connections"].value

| mv-expand Connections

| extend ConnectionKey = tostring(bag_keys(Connections)[0])

| extend Connection = todynamic(Connections[ConnectionKey])

| extend ConnectionId = tolower(tostring(Connection.connectionId))

| project ConnectionId,

    WorkflowName = name,

    WorkflowResourceGroup = resourceGroup;

ApiConnections

| join kind=leftouter WorkflowConnections on ConnectionId

| project WorkflowName, DisplayName, ConnectionStatus, StatusError,

    ConnectionResourceGroup, WorkflowResourceGroup

| order by WorkflowName asc

Automation is only as reliable as its observability. In a SOC environment, a broken Logic App is not merely a technical failure, it may represent a gap in the organization’s security response capability. A playbook that should have isolated a compromised device, revoked credentials, or sent an analyst notification can fail with real operational consequences.

• SLA and response-time commitments: Automations often support formal triage and response targets. If the workflows supporting those targets fail silently, the commitments may be missed without immediate visibility.
• Audit and compliance: Diagnostic telemetry supports evidence that automated controls ran, while monitoring helps demonstrate that failures were identified and routed to an accountable team.
• Team efficiency: Sending automation-health information directly to engineers reduces noise in the analyst queue and shortens the path to remediation.
• Prioritization: A compact Run-ID list preserves visibility across the estate, while detailed critical-only reporting concentrates investigation effort where operational impact is highest.
• Proactive operations: Without monitoring, failures are often discovered when an analyst notices that enrichment, ticketing, or response did not happen. A scheduled report makes those gaps visible earlier.

• Define a tag standard: Document the criticality key and accepted values for example, Criticality=Critical, and enforce it consistently through deployment templates or Azure Policy.
• Monitor the monitor: Create an independent alert for failure or non-execution of the monitoring Logic App, and monitor the Teams and Log Analytics connections it depends on.
• Control message size: Limit or truncate long error messages, cap action details per run when necessary, and retain a portal link to the complete diagnostic record.
• Use appropriate identities: Prefer managed identity and least-privilege access where supported. Review user-bound managed connections because their authorization can expire or be revoked.
• Account for platform variants: Consumption and Standard Logic Apps can use different diagnostic table and connection-storage patterns. Test the queries against the tables populated by your diagnostic settings.

At Wizard Cyber, we understand that the strength of a SOC is not just in its analysts, it is also in the reliability of the automation supporting them. Our team designs, builds, and maintains automation workflows with operational resilience built in from the ground up.

SOAR playbook design and maintenance: From initial deployment to ongoing optimisation, we build Logic Apps with resilient control flow, appropriate error handling, diagnostic instrumentation, and clear ownership.

Automation health reporting: We implement monitoring workflows like the one described in this blog, tailored to the environment’s scale, workflow criticality, team structure, and communication channels.

Microsoft Documentation — Monitor and collect diagnostic data for workflows in Azure Logic Apps

Microsoft Documentation — Check workflow status, view run history, and set up alerts

Microsoft Documentation — Azure Logic Apps limits and configuration

Microsoft Documentation — Create and manage Azure Monitor Action Groups

Microsoft Documentation — Customize alert notifications by using Logic Apps

Microsoft Documentation — Scheduled analytics rules in Microsoft Sentinel

Microsoft Documentation — LogicAppWorkflowRuntime table reference

Microsoft Documentation — Azure Resource Graph overview

MITRE ATT&CK — TA0040: Impact