Automation
Azure Logic Apps: diagnose a workflow before resubmitting the run
A production runbook for qualifying a failed Azure Logic Apps execution with trigger, connectors, managed identity, payload, logs, validation and rollback before resubmit.
A failed Azure Logic Apps execution often creates pressure to click Resubmit too quickly. The workflow may have received the same event twice, a connector may have expired, a managed identity may have lost a role, an HTTP action may have returned 429, a private dependency may no longer resolve in DNS, or a condition may already have triggered a partial effect. Resubmitting without qualifying state can create a duplicate: ticket, order, secret rotation, notification, database write or internal API call.
The use case is a production integration workflow processing a business or technical event: Azure Monitor alert, webhook, Service Bus message, dropped file, internal HTTP call or automation orchestration. The runbook goal is to decide whether the execution can be resubmitted, replayed with corrected payload, resumed manually, compensated, or blocked until the contract is fixed.
Freeze the execution contract
Start by describing what this execution was supposed to do. A Logic App is not only a diagram of actions. It is a production interface with a trigger, payload, connectors, identities, side effects and an idempotence rule.
Execution to qualify
Logic App: la-prod-incident-routing
Workflow: route-critical-alert
Run ID: 08585200000000000000000000000CU00
Trigger: Azure Monitor alert webhook, Service Bus, HTTP, schedule or Event Grid
Expected payload: event identifier, target, severity, correlationId
Expected effect: create or enrich a ticket, notify, call an internal API
Last certain action before failure
Partial effect already observed
Expected validation after execution
Known rollback or compensation
Questions before resubmit
Is the workflow idempotent for this payload?
Can the trigger send the same event again?
Did an external action already succeed?
Is the connector or identity the expected one?
Is the called dependency public, private or hybrid?If the team cannot say which effect has already happened, resubmit is a new production action, not a simple technical retry.
Read the real run state
The graphical view is useful, but it is not enough. Capture the run status, trigger, inputs and outputs of critical actions, retries and exact timestamps.
RG="rg-integration-prod"
LOGIC_APP="la-prod-incident-routing"
RUN_ID="08585200000000000000000000000CU00"
az logic workflow run show --resource-group "$RG" --name "$LOGIC_APP" --run-name "$RUN_ID" --output json
az logic workflow run action list --resource-group "$RG" --workflow-name "$LOGIC_APP" --run-name "$RUN_ID" --query "[].{name:name,status:status,start:startTime,end:endTime,code:code,error:error.message}" --output tableKeep sensitive inputs out of shared notes, but retain the technical evidence: failed action, response code, duration, retry attempt, correlationId and previous successful action. The resubmitted run must be comparable with the initial execution.
Separate trigger, payload and partial state
Many Logic Apps incidents come from an ambiguous event rather than the workflow itself. An incomplete webhook, an already consumed Service Bus message, a file renamed during execution or an Azure Monitor alert without the expected dimension can break a branch of the workflow.
Check the trigger
Trigger type and exact time
Payload received by the workflow
Functional identifier: eventId, ticketId, orderId, secretName, resourceId
CorrelationId passed to downstream calls
Trigger frequency, recurrence or retry behavior
Source message state: active, completed, dead-lettered, abandoned
Deduplication or lock already applied
Block resubmit when
The functional identifier is missing
The same event already produced an external effect
The payload targets too broad a scope
The trigger can replay several messages at once
The previous action succeeded but validation is unknownThe right response may be compensation, not resubmit. For example, do not create a ticket again if the ticket already exists; enrich it or attach the run to the existing identifier.
Verify connectors and managed identity
A Logic App may act through a managed connector, API connection, system identity, user-assigned identity or secret. The diagnostic must prove which identity actually called the dependency.
RG="rg-integration-prod"
LOGIC_APP="la-prod-incident-routing"
az logic workflow show --resource-group "$RG" --name "$LOGIC_APP" --query "{state:state,identity:identity,accessEndpoint:accessEndpoint,changedTime:changedTime}" --output json
az resource list --resource-group "$RG" --resource-type "Microsoft.Web/connections" --query "[].{name:name,kind:kind,changedTime:changedTime,statuses:properties.statuses}" --output json
PRINCIPAL_ID="00000000-0000-0000-0000-000000000000"
az role assignment list --assignee "$PRINCIPAL_ID" --all --query "[].{role:roleDefinitionName,scope:scope}" --output tableA 401 or 403 should not immediately lead to a wider role. First verify the connector used, expected identity, tenant, Azure scope and recent connection changes.
Qualify network and private dependencies
If the workflow calls an internal API, Key Vault, Storage, Service Bus or a private endpoint, the failure may come from the network path. Private Endpoint may be part of the path, but it is only one piece of the diagnosis: DNS, routing, firewall, identity and application logs must remain separate.
Check dependencies
FQDN called by the HTTP action or connector
Expected DNS resolution from the execution path
Private Endpoint or VNet Integration when applicable
Firewall, NSG, UDR or intermediate proxy rules
Identity presented to the dependency
Logs on API, Key Vault, Storage, Service Bus or APIM side
Resubmit is forbidden when
The resolved destination is not the expected one
The workflow accidentally reaches a public endpoint
The firewall sees only part of the conversation
The internal API already applied the action but Logic Apps timed out
Dependency logs cannot prove the applied stateFor a Logic App Standard integrated with a virtual network, also validate VNet Integration and outbound routes. For a Consumption Logic App, focus on connector type, dependency configuration and access restrictions on the called service.
Correlate effects with logs
The critical point is to know whether the workflow simply failed or failed after producing an effect. Logs must connect the Logic Apps run to the systems it touched.
let StartTime = datetime(2026-07-13T06:00:00Z);
let EndTime = datetime(2026-07-13T06:30:00Z);
let WorkflowRunId = "08585200000000000000000000000CU00";
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProvider has "MICROSOFT.LOGIC"
| where tostring(runId_s) == WorkflowRunId or tostring(correlationId_g) has WorkflowRunId
| project TimeGenerated, Resource, Category, status_s, actionName_s, code_s, error_message_s, trackingId_g
| order by TimeGenerated ascThen add dependency logs: APIM, Function, Key Vault, Storage, Service Bus, internal application or ITSM tool. If the target API returned 200 but the Logic App failed on the next action, resubmit must be bounded.
Decide resubmit, resume or compensate
The decision must be explicit. A full resubmit is safe only if the workflow can recognize an already applied effect or if no external action succeeded.
Resubmit the run as-is
The workflow is idempotent for this functional identifier
No irreversible external action succeeded
Connector, identity and dependency are back to a healthy state
Payload is complete and bounded
Post-run validation is defined
Resubmit with corrected payload
The initial trigger was incomplete
The exact target is proven
The workflow will not replay a completed action
The run is attached to a known incident or request
Resume manually
An intermediate action succeeded
The workflow has no reliable checkpoint
The next step depends on observed state
Human validation is required
Compensate or roll back
A ticket, message, secret, file or API call was already created
Resubmit would produce a duplicate
Identity or connector was wrong
Logs do not prove applied state
The idempotence contract is missingThe central question is simple: if the same payload goes through now, will the system recognize that it already processed it? If the answer is no, use controlled recovery or compensation.
Automate the diagnostic pack
A good operating mode does not only expose a resubmit button. It produces a decision pack the team can read quickly during the incident.
diagnostic_pack:
collect:
- workflow_run_state
- trigger_payload_and_functional_id
- failed_action_inputs_outputs
- connector_and_connection_status
- managed_identity_and_role_scope
- dependency_logs
- retry_history
- partial_effects
- validation_signal
decide:
- resubmit_same_run
- resubmit_with_corrected_payload
- resume_manually
- compensate_or_rollback
- block_until_contract_fix
required_evidence:
- run_id
- correlation_id
- target_resource_or_business_id
- last_successful_action
- owner_of_next_action
- rollback_or_compensation_pathThis pack can live in the incident record, attach to the change ticket, or be generated by a small collection automation. The important part is that the decision remains readable after the incident.
Validate and clean up after action
After resubmit, resume or compensation, validation must check the target system, not only the green Logic Apps status.
Validation after decision
Target run is completed or explicitly abandoned
No functional duplicate was created
Target dependency confirms the expected state
Source messages are in the expected state
Temporary retries are removed
Modified connectors or roles are back to approved scope
Logs contain runId, correlationId and decision
Workflow or contract is fixed if idempotence was missing
Rollback is incomplete when
Only the Logic Apps status is checked
A dead-letter message remains without an owner
A connector was reauthorized without trace
A temporary role remains open
The same resubmit can reproduce the duplicateThe durable correction is often a better contract: mandatory functional identifier, idempotent action, correlatable logs, bounded retry, operable dead-letter handling and a known compensation step.
Conclusion
A failed Logic App should not be handled reflexively with Resubmit. The workflow may be healthy while the trigger, connector, identity, network path or target dependency has drifted. Conversely, the workflow may already have completed the important action before failing on a secondary step.
The right runbook freezes the payload, proves identity, reads connectors, verifies the network path when needed, correlates effects and chooses between resubmit, resume, compensation or block. That decision prevents an integration outage from becoming a duplicate-action incident or a broad-permission shortcut.