Run history is the execution record for a Logic Apps workflow. It shows each time the workflow ran, whether it succeeded, failed, waited, timed out, or was resubmitted, and what happened in the trigger and actions. It is the first place an operator looks when a file did not move, an approval did not send, or a connector returned an error. It is also sensitive because inputs and outputs can contain business data unless the workflow is configured to hide them.
Logic Apps run history, workflow run history, workflow execution history, Logic App runs history, run status history
Difficulty
intermediate
CLI mappings
6
Last verified
2026-05-22
Microsoft Learn
Microsoft Learn explains that after a Logic Apps workflow runs, you can review trigger history, workflow run history, status, inputs, outputs, performance, and individual step details. Run history lists past, current, and waiting executions for troubleshooting and monitoring. and support incident review. and resolution.
In Azure architecture, run history belongs to the Logic Apps workflow runtime. For Consumption workflows it is exposed at the workflow resource level, and for Standard workflows it is tied to stateful workflow execution inside an App Service-hosted logic app. It connects integration data plane events with control-plane operations, diagnostics, Azure Monitor, connector behavior, and retry policies. Run history is not a full observability strategy by itself; production systems usually export diagnostics to Log Analytics or storage for longer retention and queryable evidence.
Why it matters
Run history matters because integration failures are often business failures with weak symptoms. A supplier invoice might not arrive, a customer notification might not send, or a downstream API might reject a payload. The workflow designer shows intent, but run history shows what actually happened. It gives timestamps, action status, retry attempts, error messages, and sometimes payload links. That evidence helps teams separate trigger problems from connector failures, data-shape issues, authentication errors, and downstream outages. It also supports compliance reviews, but only if sensitive inputs are secured and history is exported before retention limits remove old runs. It is also the safest place to decide whether replay would duplicate a business action. That discipline prevents duplicate fixes during stressful outages.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Azure portal Overview page for a Logic Apps workflow, Runs history lists recent executions with status, start time, duration, identifiers, and retry visibility. during support triage.
Signal 02
Inside a selected run, each trigger and action card shows inputs, outputs, status, retry behavior, timing, connector responses, and error details for that execution. path. during incident exports and audits.
Signal 03
In support tickets or monitoring workbooks, run IDs and tracked properties correlate business transactions with workflow execution, connector calls, timing, and failure points. during investigations. for operations review.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Prove whether a missing supplier invoice failed at the trigger, transformation, connector, or downstream ERP action.
Export run evidence before retention expires so audit teams can review an integration incident months later.
Find repeated waiting or timed-out runs caused by one slow approval service instead of blaming the entire workflow.
Use clientTrackingId or tracked properties to reconcile duplicate order events before resubmitting a failed workflow.
Verify secure inputs and outputs are enabled before granting support teams access to production workflow history.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Freight broker finds missing customs messages
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A freight brokerage used Logic Apps to send customs documents to port authorities. Several shipments showed “submitted” in the internal portal, but customs offices never received the files.
🎯Business/Technical Objectives
Identify whether failures happened before or after the outbound connector.
Avoid duplicate customs submissions during resubmission.
Preserve evidence for cross-border compliance review.
✅Solution Using Run history
Operators searched run history by tracked shipment ID and found that the trigger succeeded, the transformation succeeded, but one HTTP action returned intermittent 502 errors from the customs gateway. The workflow had retried, but not enough for the gateway outage window. The team exported run and action details with az rest, confirmed which shipments lacked a successful action result, and resubmitted only those workflow runs after verifying idempotency with the customs API. Diagnostic settings were updated to send action events to Log Analytics for longer retention.
📈Results & Business Impact
Average exception investigation dropped from four hours to twenty-two minutes.
Duplicate submissions were avoided for 96 shipments already accepted by the gateway.
Customs filing SLA compliance improved from 91 percent to 98.7 percent.
Audit packages included run status, action error, retry evidence, and resubmission approval.
💡Key Takeaway for Glossary Readers
Run history gives integration teams the evidence to repair a business process without blindly replaying every failed message.
Case study 02
Insurance claims team protects sensitive workflow evidence
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurance administrator used Logic Apps to route claim attachments to review systems. Support engineers needed run details, but the history contained claim numbers and medical notes.
🎯Business/Technical Objectives
Let support troubleshoot workflow failures without broad payload exposure.
Hide sensitive inputs and outputs in high-risk actions.
Keep enough correlation data to resolve failed claims.
Meet internal privacy review requirements before rollout.
✅Solution Using Run history
The integration team reviewed every action in the workflow and enabled secure inputs and outputs where claim attachments, notes, or personal identifiers appeared. They kept a non-sensitive tracked claim reference so operators could match run history to service tickets. Azure CLI verified diagnostic settings and role assignments, while portal run history confirmed that protected action payloads were hidden. The runbook separated viewer roles from resubmission authority and required privacy-approved evidence exports for vendor escalations. These summaries were reviewed with claims operations weekly.
📈Results & Business Impact
Support retained visibility into workflow status, timing, and action failure codes.
Payload exposure findings dropped from twelve actions to zero in the privacy review.
Claim-routing failures were resolved 38 percent faster using tracked references.
No production incident required sharing raw medical-note payloads with a vendor; privacy-review rework dropped sharply after the protected-history pattern became standard.
💡Key Takeaway for Glossary Readers
Run history is useful only when operators can see enough to troubleshoot without exposing the data the workflow is meant to protect.
Case study 03
Museum ticketing workflow reveals approval bottleneck
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A museum network used Logic Apps to approve after-hours group bookings. Customers saw long delays, but every dashboard showed the workflow eventually succeeded.
🎯Business/Technical Objectives
Find the slowest step in an otherwise successful workflow.
Reduce p95 booking confirmation time below fifteen minutes.
Avoid rewriting connectors that were not the bottleneck.
Create alerting before delays reached customer service.
✅Solution Using Run history
Engineers exported recent run history and action timing, then grouped durations by action name in Log Analytics. The payment connector completed quickly, but the manual approval action waited for a facilities mailbox that was staffed only during business hours. The team changed the workflow to route after-hours bookings to an on-call approval queue and added alerts when waiting runs exceeded twenty minutes. Run history remained the source of truth for confirming whether each booking was waiting, approved, or resubmitted. Crew leads received the run ID in every escalation ticket. for tracking.
📈Results & Business Impact
p95 booking confirmation time fell from seventy-four minutes to eleven minutes.
Customer service calls about delayed confirmations dropped 46 percent.
No connector rewrite was needed, saving an estimated three engineering weeks.
Waiting-run alerts caught two staffing gaps before customer escalations began; monthly performance reviews now focus on waiting actions, not total successful runs only.
💡Key Takeaway for Glossary Readers
Successful run history can still reveal where customers are waiting; status alone is not enough to measure integration health.
Why use Azure CLI for this?
With a decade of Azure integration work, I use Azure CLI around run history because portal filtering is fine for one workflow but weak during estate-wide reviews. There is no single high-level CLI command that solves every Logic Apps run-history scenario, especially across Consumption and Standard models. CLI still helps by listing workflows, checking definitions, calling the Logic Apps REST API with az rest, verifying diagnostic settings, and exporting evidence. During incidents, that repeatability matters more than clicking through pages while a business team waits for proof. It also lets teams gather evidence after portal retention views become crowded or filtered. It also lets teams preserve evidence before portal history is pruned.
CLI use cases
List Logic Apps workflows and identify the exact workflow resource that owns the run history under investigation.
Use az rest to export workflow runs and action details for a filtered time window or client tracking ID.
Check diagnostic settings and Log Analytics retention when portal run history is not enough for audit or trend analysis.
Before you run CLI
Confirm tenant, subscription, resource group, workflow name, Logic Apps hosting model, region, RBAC role, and whether the logic extension is installed.
Check whether exported run data may include sensitive inputs, outputs, headers, or business identifiers before writing evidence to files or tickets.
Use JSON output and pagination carefully, avoid resubmitting runs without business approval, and know whether downstream actions are idempotent.
What output tells you
Run status values such as Succeeded, Failed, Waiting, TimedOut, Cancelled, or Running show the current or final workflow outcome.
Start and end timestamps, duration, correlation, clientTrackingId, and run name connect workflow history to business events and logs.
Action-level output reveals which connector or step failed, retried, skipped, or returned a downstream error code.
Mapped Azure CLI commands
Run history Azure CLI commands
operational
az logic workflow list --resource-group <resource-group> --output table
az logic workflowdiscoverIntegration
az logic workflow show --resource-group <resource-group> --name <workflow-name>
az logic workflowdiscoverIntegration
az rest --method get --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Logic/workflows/<workflow-name>/runs?api-version=2019-05-01&$top=20"
az restdiscoverIntegration
az rest --method get --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Logic/workflows/<workflow-name>/runs/<run-name>/actions?api-version=2019-05-01"
az restdiscoverIntegration
az monitor diagnostic-settings list --resource <logic-app-resource-id>
az monitor diagnostic-settingsdiscoverIntegration
az monitor metrics list --resource <logic-app-resource-id> --metric RunsStarted,RunsCompleted,RunsFailed
az monitor metricsdiscoverIntegration
Architecture context
Architecturally, run history is the runtime ledger for integration workflows. The trigger starts the instance, actions execute connector calls or transformations, retries may occur, and the run record keeps status, timing, correlation, and action-level details. In a mature integration platform, run history feeds support operations, replay decisions, alert rules, and audit evidence. However, it should not be the only retention plan. Logic Apps history is best paired with diagnostic settings, tracked properties, Log Analytics workbooks, and business correlation IDs so operators can search by invoice number, order ID, partner, or clientTrackingId instead of manually opening individual runs. Architects should design those signals before the workflow reaches production traffic. This keeps evidence searchable after incidents.
Security
Security impact is direct because run history can expose inputs, outputs, headers, connector responses, customer identifiers, tokens, or confidential payload fragments. Logic Apps provides ways to secure inputs and outputs for actions, and operators should use them when workflows handle sensitive data. RBAC access to the logic app, diagnostic logs, and Log Analytics workspace must be controlled. Exported evidence should be scrubbed before tickets or vendor escalation. Run history does not authenticate users or encrypt payloads by itself, but it can reveal enough operational detail to create privacy, compliance, or replay risk if left broadly visible. Support procedures should define when payload screenshots are forbidden and summaries are required instead. Review exports before attaching them to tickets.
Cost
Run history has indirect cost impact. The record itself is not usually the largest bill, but failed runs can repeat connector calls, API requests, transformations, and downstream retries. Exporting diagnostics to Log Analytics or storage adds retention and ingestion cost, especially for chatty workflows with large tracked properties. Manual investigation is also expensive when operators open hundreds of runs by hand. FinOps review should examine repeated failures, resubmissions, long-running instances, noisy diagnostics, and over-retention. Good correlation IDs and selective logging often reduce both support effort and telemetry spend while preserving enough evidence for audit. Tuning noisy diagnostics can save money without losing the evidence needed for recovery. Tune retention so evidence survives without noisy overcollection.
Reliability
Reliability impact is direct because run history shows whether a workflow is healthy at the instance level. Failed, timed-out, waiting, skipped, or resubmitted runs reveal patterns that aggregate metrics can hide. A connector might succeed most of the time while one partner, trigger, or payload shape fails repeatedly. Reliable operations use run history to confirm retry behavior, inspect action duration, validate resubmission, and prove recovery after downstream outages. Run history also exposes backlog risk when waiting runs accumulate. For long-term reliability, export diagnostics before retention removes evidence and create alerts for repeated failures, not just one dramatic outage. Operators should know which failures are safe to replay and which require compensation. Track recovery evidence after fixes.
Performance
Performance impact is diagnostic rather than computational. Run history does not make the workflow faster, but it reveals which action, connector, retry, or downstream dependency consumed time. Operators can compare trigger time, action start and end times, wait states, and retry history to find bottlenecks. This is especially useful when application teams blame Logic Apps but the slow step is an external API, gateway, or approval system. For performance-sensitive workflows, review p95 action duration, waiting runs, connector throttling, and resubmission patterns. Then move recurring hot spots into alerts or Log Analytics queries. That evidence prevents teams from increasing concurrency when the true bottleneck is external. Use history to target the slow step.
Operations
Operators use run history to inspect workflow instances, find failed actions, view timing, compare retries, capture correlation IDs, and decide whether to resubmit. In production, they usually combine portal history with az rest exports, Azure Monitor logs, connector status, and business-system reconciliation. Runbooks should identify who may view payloads, who may resubmit, and how to avoid duplicate downstream effects. A good operator checks trigger history, workflow run status, action error details, tracked properties, and diagnostic logs together. The goal is not just seeing the failure; it is proving the business item reached the right final state. Mature teams also review failed-run trends before small connector errors become chronic incidents. Keep correlation fields standardized across workflows.
Common mistakes
Resubmitting a failed workflow without checking whether the downstream system already processed part of the business transaction.
Leaving sensitive action inputs and outputs visible in run history for workflows that process personal or financial data.
Assuming old run history will always be available instead of exporting diagnostics before the retention period removes evidence.