When Your Flow Breaks: Using Run History and Flow Checker to Debug Power Automate Failures

Introduction

It's Monday morning. You built a Power Automate flow last week that automatically pulls new rows from a SharePoint list, formats them into an email summary, and sends it to your manager every day at 8 AM. You're feeling great about it — until your manager walks over and says, "Hey, I never got the report this morning." You check your inbox. Nothing. You open Power Automate and see it: a little red icon next to your flow. Failed.

This is not a rare experience. Flows fail. They fail because a connection expires, because someone renames a SharePoint column, because an email address changes, because an API returns something unexpected. The question isn't whether your flows will break — it's whether you know how to find out why they broke and fix them quickly. That's exactly what this lesson teaches.

By the end of this lesson, you'll be able to open a failed flow, read its run history, trace the exact step where it went wrong, understand what the error is telling you, and use the Flow Checker tool to catch design problems before they cause failures in production. You'll go from staring helplessly at a red failure icon to confidently diagnosing and resolving the issue.

What you'll learn:

How Power Automate records flow execution in its Run History
How to navigate Run History to find a specific failed run
How to expand individual steps to read inputs, outputs, and error messages
How to interpret common error codes and what they actually mean
How to use Flow Checker to identify logic and configuration problems before they cause failures

Prerequisites

You should have:

A Microsoft 365 account with access to Power Automate (flow.microsoft.com)
At least one flow already created — even a simple one is fine
Basic familiarity with what a flow is (a series of automated steps triggered by an event)

You do not need to be a developer. No coding experience is required.

Understanding What "Run History" Actually Is

Before we click anything, let's establish what Run History is and why it exists.

Every time a Power Automate flow executes — whether it succeeds, fails, or gets cancelled — Power Automate records a log of that execution. This log is called a run. Each run has a timestamp, a status (Succeeded, Failed, Running, or Cancelled), and a detailed breakdown of every action that was attempted during that execution, including what data went into each step and what came out.

Think of it like a flight data recorder in an airplane. You might not think about it when everything is going smoothly, but the moment something goes wrong, it becomes the most valuable thing in the room. The Run History is your flight data recorder.

Power Automate stores run history for 28 days. After that, the records are automatically deleted. This means if a flow failed three weeks ago and nobody noticed, you might still have time to look — but don't wait too long.

Navigating to Your Flow's Run History

Let's walk through exactly how to get there.

Step 1: Open Power Automate

Go to flow.microsoft.com in your browser and sign in with your Microsoft 365 account. You'll land on the Power Automate home screen.

Step 2: Find your flow

In the left sidebar, click on My flows. This shows you a list of all the flows you've built. If you have many flows, use the search bar at the top of the list to find the one you're troubleshooting by name.

Step 3: Open the flow's detail page

Click on the name of your flow — not on any of the icons next to it, but directly on the flow's name. This opens the flow's detail page. You'll see the flow's description at the top, and below that, two important sections: 28-day run history and the flow diagram itself.

Step 4: Find the failed run

The 28-day run history panel shows a list of recent executions, each with:

A Start time and date
A Duration (how long it took)
A Status (Succeeded, Failed, or Cancelled)

Failed runs are marked clearly — you'll see "Failed" in red text next to the timestamp. Find the run you want to investigate (usually the most recent failed one) and click on it.

Reading a Failed Run — Step by Step

Clicking on a failed run opens the run detail view. This is where the real detective work happens.

The run detail view shows your entire flow as a vertical sequence of steps, exactly as you designed it. Each step is displayed as a collapsible card showing the action name. The flow execution works top-to-bottom, and Power Automate will mark each step with one of three visual indicators:

A green checkmark means the step ran successfully
A red X means the step failed
A grey/skipped indicator means the step was never attempted (because an earlier step failed)

The critical insight here: The step with the red X is where the failure happened. Steps above it ran successfully. Steps below it were never reached. This immediately narrows your search dramatically.

Expanding a Failed Step

Click on the failed step (the one with the red X) to expand it. You'll see three pieces of information:

Inputs — The data that was fed into this action when it ran
Outputs — What the action returned (or tried to return)
Error message — A description of what went wrong

Let's use a realistic example. Suppose your flow sends an email using Outlook, and the failed step is called Send an email (V2). When you expand it, the inputs section might show:

To: john.thompson@contoso.com
Subject: Daily Sales Report - Monday
Body: <html>...summary content...</html>

And the error section might show:

The mailbox is unavailable for the recipient john.thompson@contoso.com.

That's actually a complete diagnosis. John Thompson's email address has changed, or his account has been deactivated. The fix is clear: update the recipient email address in the flow.

This is the power of Run History. In many cases, the error message is plain English and tells you exactly what to do.

Understanding Common Error Messages

Not all error messages are self-explanatory. Here are the ones you'll encounter most often, and what they actually mean in plain terms.

"The resource could not be found"

This usually means your flow is trying to access something that no longer exists — a SharePoint list that was renamed or deleted, a folder in OneDrive that was moved, a Teams channel that was removed.

In the inputs section, look for the specific resource being referenced (a site URL, a list name, a folder path). Then go check whether that resource still exists with exactly that name. SharePoint is case-sensitive in many connector scenarios, so even a minor capitalization change in a list name can trigger this error.

"401 Unauthorized" or "Access token has expired"

This means the connection your flow is using has become invalid. Connections are the credentials Power Automate uses to talk to external services on your behalf. They occasionally expire or get revoked, especially if you changed your Microsoft 365 password recently, or if the person whose account owns the connection has left the organization.

To fix this: go back to the flow's edit view, find the step that threw the 401 error, click on the connection associated with it, and choose "Add new connection" or "Fix connection" to re-authenticate.

"Rate limit exceeded" or "429 Too Many Requests"

This means your flow is making requests to an external service (SharePoint, Dynamics 365, a third-party API) too quickly or too frequently. The service is pushing back and saying "slow down."

The fix often involves adding a Delay action between iterations in a loop, or restructuring your flow to make fewer calls. This is a more advanced problem, but recognizing the error type is the first step.

"ActionFailed: The field 'ColumnName' does not exist"

Someone renamed or deleted a column in your SharePoint list or Excel table that your flow was referencing. The fix is to go into the flow editor, find the affected step, and update the column reference to match the new column name.

Tip: This is one of the most common causes of broken flows in organizations. When someone makes "a small change" to a SharePoint list, they often don't realize that multiple flows might depend on that exact column name. It's worth documenting which flows reference which lists.

Digging Deeper: Reading Inputs and Outputs Across Multiple Steps

Sometimes a flow fails not because of a single obvious error, but because bad data entered the flow at one step and caused a cascading problem several steps later. This is where reading inputs and outputs across multiple steps becomes critical.

Here's a realistic scenario: Your flow processes rows from a SharePoint list and formats a report. The trigger fires correctly (green checkmark), the "Get items" step runs and returns data (green checkmark), but then the "Apply to each" loop fails on a specific item with a vague error about a null value.

The investigation process:

Expand the trigger step and look at its outputs. This shows you the raw data the trigger received. Does it look correct?
Expand the "Get items" step. In the outputs section, you'll see the actual SharePoint rows that were returned. Look through them. Are there any rows with missing values in fields your flow depends on?
Expand the loop step. Click into the specific iteration that failed (Power Automate shows you each loop iteration separately). Look at what value it was processing when it failed.

You'll often find that one specific row had a blank value in a field your flow assumed would always have data. For example, your flow tries to format a phone number from a contact record, but one contact record has no phone number, and your expression crashes when it encounters null.

This kind of forensic investigation — tracing data from step to step — is exactly how experienced flow builders diagnose problems. The Run History gives you everything you need to do it.

Warning: Don't assume the error is always at the step that shows the red X. Sometimes a step earlier in the flow passed along bad data silently, and the failure only becomes visible later. Always scan the inputs and outputs of the steps just before the failure too.

Using Flow Checker: Catch Problems Before They Happen

Run History helps you diagnose failures after they occur. Flow Checker is a built-in tool that helps you catch problems before your flow runs. Think of it as a spell-checker, but for your flow's logic and configuration.

Flow Checker lives inside the flow editor — the same screen where you build and design your flow.

How to Access Flow Checker

Open a flow for editing by clicking on it from My flows, then clicking the Edit button. Once you're in the flow editor, look at the top-right area of the screen. You'll see a button labeled Flow Checker (it looks like a small checkbox or shield icon, depending on your version of Power Automate). Click it.

A panel slides out from the right side of the screen. If there are issues, they'll be listed here. If everything looks good, it'll say "Your flow is ready to use" or similar.

What Flow Checker Looks For

Flow Checker identifies two types of issues: Errors and Warnings.

Errors are problems that will definitely prevent your flow from saving or running. For example:

A required field in an action is left empty (like forgetting to specify the "To" address in a Send Email action)
An expression that references a variable or dynamic content that doesn't exist
A connection that hasn't been established yet

Warnings are potential problems that won't stop the flow from saving but could cause issues at runtime. For example:

An action that has no conditions guarding against null inputs
A variable that's declared but never used

Using Flow Checker to Fix Issues

When Flow Checker lists an issue, it's not just a passive description — it's interactive. Click on any listed error or warning, and Power Automate will scroll the canvas directly to the problematic step and highlight it. This is enormously helpful in complex flows with dozens of steps, where finding the problem manually would take minutes.

For example, imagine you built a flow that uses a "Get manager" action to retrieve someone's manager from Azure Active Directory, and you forgot to connect it to a user account. Flow Checker will flag: "The 'User (UPN)' field is required." You click the error in the checker panel, the editor jumps to that step, and you can immediately fix it by mapping in the user's email address from an earlier step.

Tip: Make it a habit to run Flow Checker every time you finish editing a flow, before you save and turn it on. It takes five seconds and can save you the embarrassment of deploying a flow that fails on its very first run.

Hands-On Exercise

Let's put this into practice. If you have an existing flow, great — use it. If not, create a simple one (a manual trigger that sends you an email) and deliberately break it by putting an invalid email address in the "To" field.

Exercise Steps:

Part 1: Trigger a Failure

Open an existing flow or create a new one with a manual trigger and a "Send an email" action.
In the "Send an email" step, enter an obviously invalid email like not-an-email-address in the "To" field.
Save the flow, then manually trigger it by clicking Run on the flow's detail page.
Wait 30 seconds, then refresh the page.

Part 2: Investigate the Failure

In the 28-day run history section, find the failed run (marked in red as "Failed").
Click on it to open the run detail view.
Identify which step has the red X.
Click on that step to expand it.
Read the error message. Write it down or take a mental note of what it says.
Look at the Inputs section. Do you see your invalid email address?

Part 3: Use Flow Checker

Go back to the flow's detail page and click Edit.
Click Flow Checker in the top-right.
Observe whether the invalid email generates an error or warning.
Click any listed issue to jump to the relevant step.

Part 4: Fix It

Replace the invalid email with your actual email address.
Run Flow Checker again to confirm no errors remain.
Save the flow.
Trigger it again manually and confirm it succeeds in Run History.

Common Mistakes and Troubleshooting

"I don't see a Run History at all."

If your flow has never been triggered, there will be no runs to show. Make sure the flow is turned on (not disabled) and has been triggered at least once, either by its trigger event or manually.

"The run says Failed, but all the steps show green checkmarks."

This can happen when the failure occurs in the trigger itself rather than in an action step. Expand the trigger step (the very first card at the top of the run detail view) and check its outputs for error messages.

"The error message is a long code like 'InternalServiceFault' with no explanation."

Some error codes are cryptic. In these cases: copy the full error message text, go to Microsoft's Power Automate community forum (powerusers.microsoft.com), and search for the exact error code. These forums are excellent and the error codes are well-documented by the community.

"My flow fails intermittently — sometimes it works, sometimes it doesn't."

Intermittent failures are often caused by timeout issues or rate limiting. Look at the Duration column in Run History — do the failing runs take significantly longer than the successful ones? If so, a service your flow depends on is taking too long to respond and Power Automate is timing out. Look into whether you can optimize the number of API calls your flow makes.

"Flow Checker shows no errors, but the flow still fails."

Flow Checker catches design-time problems, not runtime problems. It can't know that a SharePoint column will be renamed tomorrow or that an API will return unexpected data. Run History is still your primary tool for runtime failures.

Summary and Next Steps

You now have the two most important debugging tools in Power Automate in your toolkit. Let's recap what we covered:

Run History is the detailed log of every flow execution. It shows you the exact step where a failure occurred, the data that went into that step, and the error message explaining what went wrong. You access it by clicking on a flow's name, then clicking on a specific run in the 28-day run history panel.

Flow Checker is the design-time validation tool that catches missing required fields, invalid expressions, and broken connections before your flow ever runs. Access it from the top-right of the flow editor.

Together, these two tools cover the full debugging cycle: Flow Checker prevents problems before deployment, and Run History diagnoses problems after they occur.

The debugging skills you've built here apply to every flow you'll ever build. As your flows become more complex — with loops, conditions, and multiple connected services — the same approach applies: find the red X, read the error, trace the data, fix the root cause.

Where to go next:

Learn about error handling in Power Automate — using "Configure run after" settings to build flows that handle failures gracefully instead of just stopping
Explore Power Automate's expression language to understand how to write dynamic conditions and transformations that are more resilient to missing or unexpected data
Practice building a flow with intentional edge cases — what happens if a SharePoint list is empty? What if an email field is blank? Testing these scenarios proactively will save you many future debugging sessions

Every expert flow builder has spent hours staring at failed runs. The difference between a beginner and a pro isn't that the pro's flows don't fail — it's that the pro knows exactly where to look when they do.

Using Power Automate Run History and Flow Checker to Debug and Fix Failing Flows