How to read the run history in Power Automate correctly and find the cause of a failed run.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
Why Power Automate throws error 429 and how you can specifically fix throttling through concurrency control and batching.
Try-Catch pattern in Power Automate: use scopes and Configure run after to catch, log, and report errors in a controlled way.
You recognize stuck executions in n8n by status indicators that won't move. Here's how to set EXECUTIONS_TIMEOUT correctly and find the cause.
Reading error codes and expression errors in the run history takes time that's often missing in daily business, especially when a flow completes but the result is still wrong. NordFlux takes over ongoing monitoring of your Power Automate flows and fixes errors before they become an operational risk. In our first conversation, we show how managed operations lower your error rate.