Power Automate: Reading Run History and Finding Errors

A flow doesn't run as expected, but what exactly is causing it is rarely clear at first glance. Power Automate logs every single execution in the run history, including start time, duration, status, and, in case of failure, the exact step where it got stuck. If you know where to find this information and how to read it, you'll usually find the cause within a few minutes instead of after a long trial-and-error process.

This article shows you where to open the run history in Power Automate, how to read a failed run step by step, and which error codes and expression errors come up most often in practice. This way you stay in control of your flows, even when something goes wrong.

Where to find the run history

Sign in at make.powerautomate.com and select My flows. In the row of the affected flow, either open the flow directly or use the three-dot menu to open the Details page. There you'll find the Run history section (in older interfaces also called 28-day run history), which lists each run as its own row with start time, duration, and status. A green checkmark means success, a red exclamation mark means an error.

Good to know: by default, Power Automate only stores run data for 28 days. If your flow runs infrequently, or if you need the history to remain traceable for longer, it's worth taking a look at the details on this, because older runs simply become impossible to find afterward. Microsoft describes the details, including the option to retain the run history longer via Dataverse, in the article Missing runs or trigger history for a flow.

Reading a failed run step by step

Click the start date of the failed run in the list to go to the detail view. There, the entire flow appears as a chain of actions, and at least one step is marked with a red exclamation mark. That's the actual point of failure; all actions before it ran successfully.

• Click the marked step to expand it.
• In the panel on the right, under Details, you'll see the status code and the specific error message from the connector.
• Also check the Inputs and Outputs tabs of the previous steps, because the actual cause is often not in the failed step itself, but in an incorrect or empty value that was passed down from further up.
• If the error occurs inside a scope block, several subsequent actions may be marked as "skipped". That's normal, because a failed scope aborts all dependent actions nested within it.

For anyone who prefers a structured approach over clicking around freely, Microsoft has published a kind of decision tree: depending on whether the flow doesn't save at all, doesn't trigger, an action fails, or it simply produces the wrong result, the article Troubleshoot cloud flow issues leads to the matching section with concrete checks.

The most important error codes at a glance

Most errors in a failed action can be roughly categorized by the status code before you even read the error message in detail.

| Code | Meaning | First check |

| --- | --- | --- |

| 401 | Authentication failed | Re-authenticate the connection under Connections |

| 403 | Access denied | Check permissions on the target resource, then clarify DLP policies with the admin |

| 404 | Resource not found | SharePoint list, file, mailbox, or endpoint was renamed, moved, or deleted |

| 429 | Too many requests (rate limit) | Add a delay or enable retry with backoff in the action settings |

| 500 / 502 | Server error at the target service | Usually temporary, retry the run via Resubmit |

400-range codes almost always point to a problem with your own configuration, while 500-range codes tend to indicate a temporary problem at the called service and can often be resolved by simply retrying the run.

Recognizing and categorizing expression errors

Two error messages come up especially often in the run history: "Invalid template" or "Unable to process template language expressions", as well as "ExpressionEvaluationFailed". Both mean that an expression is syntactically incorrect or refers to a value at runtime that doesn't exist at all. Typical causes are:

• A reference to dynamic content from a step that wasn't executed at all because a condition wasn't met.
• An incorrect data type, for example a string where a number is expected.
• An empty or null value that gets processed further without a safeguard. A `coalesce()` function or an upstream `if(empty(...))` check catches that.

If the history instead reports "ActionFailed. An action failed. No dependent actions succeeded.", the actual trigger is usually a parent scope block. Instead of investigating each of the subsequent actions marked as failed individually, it's worth specifically searching for the first failed action within the scope, because that's where the actual cause lies.

When the flow runs through but the result is wrong

Not every error shows up as a red exclamation mark. Sometimes the flow runs completely green, but the wrong result appears at the end, for example an approval email that wasn't sent, or a field that was filled in incorrectly. In this case, the classic look at red errors doesn't help; instead, you have to go through each action individually and compare inputs with outputs.

• In conditions, check the values actually being compared. Common pitfalls are leading spaces, capitalization ("Approved" versus "approved"), or a numeric value arriving as a string.
• For an Apply to each loop, it's worth looking at the input the loop runs through. If the array contains more or fewer entries than expected, the problem usually already lies in the preceding retrieval step.
• If the flow updates a record and reads it again right afterward, a short delay of a few seconds between writing and reading may be necessary so that no stale data comes back.
• For targeted debugging, inserted Compose actions at key points in the flow help. They output exactly the value you want to check and can be viewed afterward in the run history, without changing the actual flow.

Microsoft describes these and other scenarios in detail, including concrete examples of authentication errors and Copilot-assisted troubleshooting in the new designer, in the article Troubleshoot a cloud flow.

When it's worth checking the community

Not every error message is unambiguous, especially with unusual combinations of connector and data source. In such cases, it's usually faster to copy the exact error text and search for it in the Power Automate community forums at powerusers.microsoft.com instead of trying out every possible cause yourself. Often, someone else has already posted exactly the same error message and found a working solution for it.

Anyone who regularly reviews the run history quickly develops a feel for which errors are harmless and which are structural. Anyone who would rather rely on an experienced outside perspective, or wants a flow set up robustly from the start, will find in NordFlux's Power Automate consulting a single point of contact with a fixed price instead of timesheets.

Frequently asked questions

How long does a failed run stay visible in the run history?

28 days by default. After that, the run disappears from the normal run history, even though the flow itself continues to exist. Anyone who needs longer traceability can retain the run history via the Dataverse connection or manually document the error details before they're deleted.

Why are several steps after the actual error marked as skipped?

This typically happens when the error occurs inside a scope block. If an action within it fails, all dependent, downstream actions in the same block are automatically aborted and shown as skipped. The actual cause is almost always in the first failed action within the scope.

What does error code 429 mean in the run history?

A 429 indicates that the called service received too many requests in too short a time and is therefore rejecting the request. The usual fix is a short delay before the affected step, or enabled retry logic with backoff in the action settings.

The flow runs through green, but nothing visible happens. What's the reason?

In that case, it's usually not a technical error but a logic problem, for example a condition that evaluates differently than expected, or a loop that hits an empty array. It helps to open each action in the history individually and compare the actual inputs and outputs with your expectations.

Do I have to restart the entire flow for every failed run?

No. In the detail view of a failed run, the Resubmit option is available. It repeats the run with the same input data once you've fixed the underlying cause, for example by re-authenticating a connection or correcting a faulty action.