Phase 5 · Power Automate · Level 2 · Practitioner
Run history: reading and fixing a failed flow
By the end, you'll be able to…
- Open a flow's run history and tell a successful run from a failed one
- Read a failed run to find which step broke and why
- Fix the three most common causes and safely re-run the failed item
Why it matters
Every flow fails eventually: a connection expires, a folder gets renamed, a form field comes through empty. What separates a practitioner from a beginner isn't building flows that never break; it's being able to open the wreckage, read exactly what went wrong, and fix it in five minutes. This lesson turns 'my flow stopped working' from a mystery into a routine you can follow every time.
Run history is the flow's diary
Because flows run out of sight, you need a record of what they've done, and that's the run history: a dated list of every time the flow triggered, each marked with a tick for success or a cross for failure. It's the first place you look for anything, from "did it run at all?" to "why did it break on Tuesday?". You reach it from My flows, opening the flow, where the run history is shown right there, one row per run, newest first.
One durable fact worth knowing: this history is kept for a limited window (28 days at the time of writing), so a failure from two months ago won't be there. If you need a longer record, you capture it as the flow runs rather than relying on the history to hold it forever. For everyday fixing, though, the recent list is exactly what you need.
Let's carry one Fernway example through. Dan's expense-filing flow (save the receipt, log the amount, post to the Finance channel) worked for weeks and has just started failing. Here's how you'd find out why and fix it.
Step 1: Find the failed run
Open the flow from My flows and look at the run history. Successful runs show a tick; Dan's recent ones show a cross. Note when the failures started: a cluster of crosses beginning on one date is a strong clue, because something changed around then (a password reset, a renamed folder, a new form field). Click the most recent failed run to open it. You're now looking at that single run, laid out step by step.
Step 2: Read which step broke, and why
Inside a failed run, each step shows its status, and the one that broke is marked with a red icon. Usually the first red step is the culprit, and everything after it simply never ran. Open that step. Power Automate shows the error message for it, and the error message is the whole point: it almost always tells you what went wrong in plain-ish language. Reading it carefully, rather than panicking, is 80% of fixing a flow.
The errors cluster into a few recognisable types, and the wording tells you which:
- Authentication / connection: the message mentions "Unauthorized", or a code like 401 or 403. It means the flow's signed-in link to an app has stopped working, and the classic cause is a password change or an expired connection.
- Not found / bad reference: the message names something it couldn't find: a folder, a file, a table, a column. Usually something was renamed, moved or deleted after the flow was built.
- Bad or missing data: the message complains a required field was empty or the wrong type. Often a real-world input didn't match the tidy one you tested with: a blank optional field, an unexpected format.
- Temporary / transient: codes like 500 or 502 mean the other service hiccupped, not that your flow is wrong. These often succeed on a simple re-run.
Step 3: Fix the cause, then re-run the failed item
Each type has a matching fix, and you don't rebuild the flow; you correct the one thing and re-run.
Connection problems are fixed by signing in again. In the failed run or the flow's connections, find the one flagged as broken and use its Fix connection option to re-authenticate. This is Dan's most likely cause if his failures began right after an IT password reset.
This step failed with the error "The specified folder does not exist". Explain in plain English what that usually means in Power Automate and the most likely thing I should check or change to fix it.
Why this works: Pasting the exact error text and asking for plain-English cause and fix turns an opaque message into a next step. Because you'll verify the fix by re-running, this is a safe use of Copilot; it's suggesting where to look, not silently changing your flow.
Not-found problems are fixed by pointing the step at the thing that now exists: re-select the folder, file, table or column, save, and you're done. If Dan's "Receipts" folder was renamed, the fix is choosing the new name in the Excel or OneDrive step.
Bad-data problems are fixed by making the flow cope with the awkward input, for instance adding a condition that skips or defaults an empty field (the empty(...) check from the expressions lesson), so a blank comment no longer breaks the run.
Once you've corrected the cause, you don't have to wait for the situation to happen again to test the fix. Open a failed run and use Resubmit, which re-runs the flow on that exact original input. For a transient 500/502 error, resubmitting alone often just works. For a real fix, resubmit after editing to confirm the same input now succeeds.
I re-authenticated the Outlook connection that was failing. List what I should do to confirm the flow is properly fixed, including which run to resubmit and what to check in the destination rather than just looking for green ticks.
Why this works: Getting Copilot to list what to re-check after a fix turns 'I think it's sorted' into a short verification. It names the failed input, the resubmit, and confirming the real result, the same 'check the actual output, not just the ticks' discipline from earlier lessons.
Prevention: get told, don't discover
Fixing failures is a skill; not having to notice them yourself is a habit. Turn on failure notifications (the highest-value habit from Level 1) so Power Automate emails you the moment a run fails, turning "I found out at month-end" into "I knew within minutes". And glance at run history for your important flows now and then, especially after any password change or IT update, which are the events most likely to break connections.
Change this flow so that if any step fails, it sends me an Outlook email with the flow's name and the error message, so I'm told immediately instead of finding out later.
Why this works: This asks for the 'notify me on failure' pattern in plain English, naming both the trigger (any step failing) and the action (email with the details). It's the difference between discovering a silent failure weeks late and being told at once, worth adding to every flow that matters.
Try it now
Common mistakes
- Rebuilding the whole flow instead of reading the error. The error message usually names the exact problem. Deleting and starting again wastes time and often reintroduces the same fault. Read first, fix the one thing.
- Fixing the last red step instead of the first. Once one step fails, later steps fail too because they never ran. The first red step is the real cause; steps below it are just downstream casualties.
- Assuming every failure is your fault. A 500 or 502 is the other service hiccupping, not a bug in your flow. Try a resubmit before rewriting anything.
- Trusting a resubmit that went green without checking the result. A resubmitted run showing ticks tells you it ran, not that it did the right thing, the same over-trust trap as everywhere else. After fixing a flow, open the destination and confirm the actual file, row or message is correct, not just that the run looks happy. The responsibility for the outcome is still yours, fix or no fix.
Keeping current
The exact labels (where "Resubmit" and "Fix connection" sit, the retention window) shift with portal updates, but open history, read the error, fix the cause, resubmit is durable. Microsoft's Troubleshoot a cloud flow and Understand flow failure notifications on Microsoft Learn track the current screens. Accurate as of 13 July 2026.