Power Automate failure email but no failed run? How to investigate it

Power Automate has emailed to say a flow failed. You open the flow, scan the run history—and there is no red run to inspect.

Do not dismiss the email as false. The failure may be real even though its run is no longer visible in the place you are looking.

The most common causes are:

the run started near the edge of Power Automate's history-retention window;
a long-running approval or delay reached the 30-day maximum run duration;
you opened the wrong environment, flow or account;
the email is a weekly digest rather than an alert for one run; or
the visible failure is a later cascade, while the useful error sits on the first failed action.

This guide shows you how to identify which case you have and how to stop important processes depending on an email you cannot investigate.

The two failure emails Power Automate sends

Microsoft documents two different notification types in Understand flow failure notifications.

Notification	What it means	Important limitation
Per-run failure alert	Power Automate recognised a failure for which it can offer an actionable repair suggestion	It is not sent for every failure. After one is sent for a flow, Microsoft applies a 28-day cooldown before another per-run alert for that flow
Weekly failure digest	A summary of failures across your environments during the previous week	It can contain failures that did not produce an individual alert

The recipients matter too. Microsoft says per-run alerts go to the flow owner and co-owners—not automatically to every environment or tenant administrator.

Start by reading the email rather than clicking straight through it. Record:

the flow name;
environment, if shown;
date and time of the failure;
error or connector named in the message;
whether it describes one run or a weekly summary; and
the account that received it.

Those details give you something to match when the portal link is unhelpful.

Why the failed run may have disappeared

Microsoft's documentation currently describes two closely related windows:

the main Power Automate limits page lists a 30-day maximum run duration and 30-day run retention in storage, both calculated from the run's start time; and
Microsoft's missing run history troubleshooting article says default run data is visible for 28 days.

That documentation difference is one reason not to diagnose the problem from a single number.

The safe operational assumption is that the standard designer history is short-lived. Capture evidence elsewhere when a process is important or can wait for weeks.

The awkward long-running approval case

Suppose a flow starts an approval and waits.

Microsoft calculates the 30-day run limit from the original start time, including pending steps such as approvals. If nobody responds before that limit, the pending action times out.

By then, the run may also be at or beyond the history window presented in the designer. The alert can therefore be genuine while the ordinary history page gives you little or nothing useful to inspect.

This is not a “false failure.” It is a real timeout with poor surviving evidence.

A seven-step investigation

1. Confirm the environment and identity

Open Power Automate directly, then choose the environment named in the message or the environment that owns the flow.

Check that you are signed in with the account that owns or co-owns it. A link can open a similarly named flow in the wrong environment, especially when development, test and production copies exist.

2. Match the exact flow

Check the flow's internal details, owner and last modified date. Do not assume two flows with the same display name are the same object.

If the email concerns an older version or a flow that was replaced, the current flow's green history does not disprove the older failure.

3. Check the run's start time, not only the email time

A flow that fails after waiting for weeks is aged from when it started. Look backwards from the email time for approvals, delays, webhook waits or other pending work that began near the retention boundary.

4. Use the administrative monitoring view where available

Microsoft recommends the Monitor experience in the Power Platform admin centre for administrators who need an environment-wide view of failures. It includes failures that do not generate individual emails.

The automation centre has scope and ownership limitations, particularly around which solution-aware flows and runs a user can see. Treat “not listed” as an access or retention question before treating it as proof that no run failed.

5. Find the first failed action

A failed action can cause several later actions to be skipped or marked as failed. Microsoft calls these later results cascade failures.

Open the earliest failed action in the run and record its error code, inputs, outputs and correlation identifiers. That is normally more useful than the final red action.

Be careful with sensitive inputs and outputs. Do not paste access tokens, personal data or connector secrets into a ticket or spreadsheet.

6. Check connections and throttling

Per-run repair alerts commonly concern broken connections, throttled actions or recognised connector failures.

Check the connection owner, authentication state, connector health and whether the account still has permission to the target resource. A flow can keep its definition while the connection behind it expires or loses access.

7. Do not resubmit blindly

Before selecting Resubmit, decide whether the failed run might already have written some data, sent an email, created an approval or called an external service.

Make the operation safe to retry or use a correlation ID to check whether the work already completed. Replaying a partially successful run can create duplicates or send the same instruction twice.

How to preserve evidence for important flows

The designer history should not be your only audit trail for a business-critical process.

At minimum, write a small operational record to SharePoint or Dataverse containing:

a unique business or correlation ID;
flow and environment name;
process status;
current stage;
started and last-updated times;
owner or support queue;
external reference returned by the target system; and
a sanitised error category when the process fails.

Use a top-level Scope for the main work and separate scopes for failure and cleanup paths. Configure the failure scope to run after failure, timeout or skip as appropriate.

That record should tell support staff what business item is stuck without copying every action input and output.

For solution-aware cloud flows, Microsoft also documents cloud flow run history in Dataverse. It stores FlowRun records for eligible solution flows and allows administrators to manage retention according to the environment's storage and configuration.

It is not a universal switch for every personal or non-solution flow.

Redesign processes that can exceed 30 days

A single cloud-flow run cannot wait indefinitely. Buying a different licence does not remove the documented 30-day maximum run duration.

For work that may take longer, use a relay pattern:

Create a durable process record. Store the business ID, status, owner, deadline and next action in SharePoint, Dataverse or another governed system of record.
Start the request. Create the approval or external task and store its reference.
End or bound the first run. Give waits an explicit timeout and a timeout branch rather than leaving one run open without a recovery path.
Monitor outstanding work separately. Use a scheduled flow for reminders, escalation and stale-item reporting.
Resume with a new trigger. When a response or state change arrives, start another run that reloads the durable record and continues from the recorded stage.
Make every transition idempotent. A repeated trigger must not approve, email or post the same business transaction twice.

Microsoft's cloud-flow error reference also recommends splitting processes that exceed 30 days into multiple runs with shared state.

Simply calling a child flow does not make a 40-day wait reliable. The important change is moving the process state out of one ageing run.

What Premium does—and does not—fix

The previous version of this article claimed that Power Automate Premium automatically extended history to 90 days and completely solved missing diagnostics. Microsoft's current documentation does not support that blanket statement.

Licences affect connectors, performance profiles, request allocations and other capabilities. Run-history options also depend on whether the flow is solution-aware and whether Dataverse run history is being used.

Check the current Power Automate licence types for the features you actually need. Do not buy Premium solely on the strength of an old “90-day history” claim.

A small production-readiness test

Before relying on the revised flow:

Trigger it with a known test record and correlation ID.
Confirm the operational record reaches Running and then Complete.
Force one safe action to fail and confirm the first error is captured.
Force a short timeout and confirm the timeout branch changes the business status.
Retry the same correlation ID and confirm it does not duplicate the output.
Confirm the named support owner can find the record without using your account.

This tests the recovery design, not only the happy path.

Frequently asked questions

Why did Power Automate email me when no failed run is visible?

The run may have aged out of the visible history, started in another environment, belonged to an older flow version or appeared in a weekly digest. A long-running approval can also fail at the 30-day run limit when little history remains visible.

Can a Power Automate cloud flow run for more than 30 days?

Microsoft documents a maximum duration of 30 days for one cloud-flow run, including pending approvals and delays. Longer processes need multiple runs with durable state stored outside the run.

Does Power Automate Premium give every flow 90 days of run history?

Microsoft's current documentation does not describe a universal Premium entitlement that changes every flow's visible history to 90 days. Solution-aware FlowRun data in Dataverse has separate retention configuration and storage considerations.

Why do Microsoft pages mention both 28 and 30 days?

The main limits page lists 30-day run duration and storage retention, while troubleshooting and Dataverse pages describe a 28-day default history window. Design monitoring so it does not depend on evidence surviving until either boundary.

Should I resubmit a failed run from the email?

Only after checking whether part of the run already succeeded. Confirm the operation is safe to retry or use a business/correlation ID to prevent duplicate records, messages or external transactions.

Official Microsoft references

Building flows that somebody else must support? Join the Power Automate Builders Space for practical patterns, current Microsoft changes and peer discussion.