How to Monitor Power Automate Flow Runs

For one cloud flow, open its details page and use Run history to inspect each execution and its actions. Use Analytics for trends such as run volume, success rate, failure rate, duration, and bottlenecks. For environment-wide visibility, use the Power Platform admin center’s Monitor experience. For retention and queryable telemetry beyond the standard view, use Dataverse flow-run records or Application Insights.

Power Automate monitoring has several scopes. Choosing the wrong one is the most common reason teams miss failures or expect real-time data from a report that refreshes about once every 24 hours.

1. Choose the right monitoring surface

Surface	Best for	What it shows	Limits
Flow details and Run history	Investigating one flow	Individual runs, action status, duration, inputs, outputs, and errors	Standard history is available for 28 days by default
Flow Analytics	Trend review for one flow	Run counts, success and failure rates, execution time, and bottlenecks	Rolling 30-day summary; refreshes approximately every 24 hours; not real time
Power Platform admin center Monitor	Environment-wide failure investigation	Failed runs across flows	Requires the appropriate administrative access
Admin center analytics	Environment-level usage and patterns	Run and usage patterns over the documented history period	Views and permissions vary by tenant
Dataverse FlowRun records	Longer retention and queries	Start/end time, duration, status, trigger type, error code, and error message	Requires configuration; retention and feature limitations apply
Application Insights	Deeper telemetry and custom alerts	Flow, trigger, and action telemetry, performance, failures, usage, and custom alert conditions	Requires environment-level setup and eligibility checks
Purview audit logs	Governance	Who created, edited, deleted, or changed permissions on flows	Does not contain individual runtime executions or connector calls

Microsoft’s flow-monitoring guidance describes flows as systems that require ongoing observation rather than a one-time setup.

2. Inspect a single flow’s run history

Open Power Automate and select My flows.
Open the cloud flow you need to investigate.
On the details page, locate Run history.
Select a run to see its overall status, start time, duration, trigger details, and action-by-action results.
Expand the first action that failed and read its error code and message.

Do not start with the last red action. Dependent actions can be marked failed after an earlier action fails, even though they did not perform their own work. The first actual failure usually identifies the broken connector call, expression, condition, or trigger path.

What to record during an investigation

Run ID and start time
Trigger name and trigger inputs
First failed action
Error code and message
Action duration and retry behavior
Relevant connector, HTTP status, or service request ID
Whether the failure is isolated or repeated across runs

3. Use Analytics for trends, not live alerting

Open the flow’s Analytics view to review aggregate behavior. The documented view is a rolling 30-day run-history summary and refreshes approximately every 24 hours. Use it to answer questions such as:

Is the flow running as often as expected?
Is the failure rate increasing?
Which actions consume the most execution time?
Did a change affect duration or success rate?

Analytics is not a real-time dashboard. A run that failed minutes ago may not appear in the report yet. The feature is also not currently available in government and sovereign clouds according to Microsoft’s monitoring documentation.

4. Monitor every flow in an environment

When the question is “Which flows failed across this environment?”, use the Monitor experience in the Power Platform admin center. Microsoft documents this as the route for seeing failed runs across flows without relying on the narrower conditions that govern per-run notification emails.

Open the Power Platform admin center.
Select the environment you need to review.
Open the monitoring or analytics area.
Filter for failed runs and narrow by time, flow, owner, or environment where the view supports those filters.
Open a run to continue diagnosis in the flow’s detailed history.

Admin-center analytics also provides environment-level run and usage patterns. Its documented history period is 28 days, so export or route telemetry elsewhere when your incident process needs a longer window.

5. Configure failure notifications carefully

Failure emails are useful prompts, but they are not a complete alerting system. Per-run alerts are sent for some known, fixable failures. General action failures, cascade failures, and other conditions may not generate an email. Microsoft also documents a 28-day cooldown for another per-run alert for the same flow, and alerts may need to be enabled in the flow settings.

Enable the flow’s failure notifications where available.
Treat an email as a signal to investigate, not proof that every failed run will produce a message.
Use the admin-center Monitor experience to find failures that did not generate an email.
Use the documented weekly digest for a summary across environments.
For production systems, add a durable telemetry and alerting path with Dataverse or Application Insights.

6. Diagnose missing runs

If the flow saved successfully but no runs appear in run history, first determine whether the trigger fired.

Verify that the source event actually occurred.
Check the trigger connection and authentication.
Review trigger conditions. A trigger condition can filter out an event before a run is created.
Confirm that the flow is turned on and saved in the expected environment.
Check timezone assumptions when an event depends on a schedule.
Use the source system’s own logs to confirm that it sent the event.

Separate trigger problems from action problems. An empty history usually points to trigger delivery, trigger conditions, connection state, or environment selection rather than an error inside a later action.

7. Keep run data longer than the default window

The standard run-history view has a default availability window of 28 days. If an audit, incident review, or reliability program needs longer retention, Microsoft documents Dataverse cloud-flow run history as an option. FlowRun records can include start and end time, duration, status, trigger type, error code, and error message.

Dataverse retention checklist

Confirm that the feature is enabled and supported in your environment.
Define the retention period required by your operations or compliance process.
Query only the metadata needed for reporting to control storage and cost.
Document feature limitations before promising a specific retention duration.
Restrict access to run data because error messages and metadata can contain operational details.

Dataverse records are useful for reporting and trend queries, but they do not automatically replace detailed runtime diagnostics in the Power Automate interface.

8. Add Application Insights for deeper observability

Application Insights, part of Azure Monitor, can receive flow, trigger, and action telemetry at the environment level. It is appropriate when you need performance analysis, custom alert conditions, or a central operations view.

Confirm that your environment and licensing meet the current Application Insights requirements.
Connect the environment to an Application Insights resource using the supported Power Platform configuration.
Allow telemetry to arrive before designing alerts.
Create alerts around the conditions your team can act on, such as repeated failures, abnormal duration, or a rise in failed actions.
Document sampling, retention, access, and ownership.

Application Insights requires configuration and should be evaluated against your tenant’s current regional and licensing availability. Use it for telemetry and alerting; continue using the flow run details page for the complete interactive diagnosis of an individual run.

9. Use the correct role for operations work

The Power Automate Operator role allows visibility into cloud-flow run metadata through Dataverse. It does not grant the detailed runtime capabilities that a full run-history investigation may require.

An operator may not be able to see per-action inputs and outputs, expression evaluation results, retry details, the full trigger payload, or the complete runtime history served by the flow interface. Operators also cannot resubmit or cancel a cloud run. Assign access based on the diagnostic tasks the person must perform, and avoid assuming that metadata visibility equals full run access.

10. Build a practical monitoring workflow

Detect: Review admin-center Monitor, a weekly digest, Application Insights alerts, or your incident system.
Scope: Decide whether the problem affects one run, one flow, or the whole environment.
Inspect: Open the run and find the first action that actually failed.
Classify: Label the issue as a trigger problem, connector or authentication error, data problem, expression or logic error, throttling issue, or downstream outage.
Recover: Correct the cause, then resubmit only when replaying the event is safe and supported by your process.
Learn: Store the incident’s run ID, error, duration, owner, and resolution in your operational record.

11. Troubleshooting common monitoring problems

Symptom	Likely cause	Fix
No run appears	Trigger did not fire or a trigger condition filtered it	Verify the source event, trigger connection, conditions, and environment
Only the final action is red	An earlier dependency failed	Trace upward and inspect the first actual failure
No failure email arrived	The failure type is outside per-run alert coverage, alerts are disabled, or the cooldown applies	Use admin-center Monitor; check settings and the 28-day notification cooldown
Analytics looks stale	The report refreshes approximately every 24 hours	Use run history or real-time telemetry for current incidents
Old runs cannot be found	The standard history window has expired	Use Dataverse run history or another configured telemetry destination
Operator cannot inspect action details	Operator access exposes metadata but not full runtime inputs and outputs	Escalate to a role with the required diagnostic permissions
Purview has no execution record	Purview audit logs track lifecycle and permission events, not runtime runs	Use run history, Dataverse, admin analytics, or Application Insights

12. Performance, reliability, and cost considerations

Performance: Use Analytics to find slow actions, then inspect action duration and connector behavior in individual runs. Avoid treating a 24-hour aggregate report as a latency monitor.
Reliability: Combine per-flow inspection with environment-wide monitoring. A single alert channel can miss failures.
Retention: Export or store the metadata required for incident analysis before the 28-day standard window expires.
Access: Give operators the minimum role that still supports their work, and define an escalation path for payload-level diagnosis.
Cost: Application Insights and Dataverse storage can create ongoing platform costs and retention decisions. Confirm current licensing, region, and tenant configuration before rollout.
Noise: Alert on conditions that have an owner and response path. A high-volume alert with no runbook becomes another missed signal.

13. Or skip the browser setup

If your workflow also needs screenshots of run-history pages, incident evidence, or dashboards, ScreenshotNeo provides a website screenshot API and MCP server. It accepts a URL and returns a PNG, JPEG, WebP, or PDF.

Use the same one-call pattern from the ScreenshotNeo documentation:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://learn.microsoft.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://learn.microsoft.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://learn.microsoft.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing result. Its MCP server lets Claude, Cursor, and other MCP clients call take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Is Power Automate Analytics real time?

No. The individual-flow Analytics report is a rolling 30-day summary that refreshes approximately every 24 hours.

How long are runs kept by default?

The standard run-history view has 28 days of default availability.

What should I inspect first in a failed run?

Find the first action that actually failed. Later red actions may only be dependent failures.

Can Purview show every flow execution?

No. Purview audit logs cover lifecycle and permission activity, not individual runtime executions, action calls, or connector requests.

What is the best option for long-term reporting?

Use Dataverse FlowRun records or Application Insights after checking current feature, licensing, retention, and regional availability.