Monitor and troubleshoot
1. Monitor and troubleshoot
More complexity means more places things can go wrong. We'll cover three pillars, starting with testing before things break, then monitoring while flows run, and finally troubleshooting when run history turns red.2. Flow Checker
Before you test, Flow Checker tests for you. Each save scans the flow for errors and warnings. Errors block the save outright, like a required field missing, a malformed expression, or an unreferenced variable. Warnings let the flow save but flag potential issues, like an action referencing data the trigger doesn't provide. You can also run Flow Checker manually by clicking the stethoscope icon in the designer toolbar. Treat it as your first line of defense before Test.3. Test modes
The Test button sits top-right in the designer, and it has two modes. Save first, because Test won't run on unsaved changes. Then choose Manually, where you fire the trigger yourself with your own inputs, or Automatically, where Power Automate replays one of your recent runs. Automatically is perfect when you've just fixed a bug and want to confirm the broken payload now passes. One habit ties all of this together, which is to test after every step you add rather than once at the end. The smaller the change, the easier the diagnosis when something breaks.4. Run history deep dive
Run history is your most important debugging tool, and remember each step shows the status icon you've already met, with green for succeeded, amber for running or waiting like during an approval, red for failed, and grey for skipped. In Marco's expense approval, the Create approval action failed and the three steps below it turned grey. The instinct is to investigate the most important-looking step, but if it's grey, it was just skipped along with everything beneath the failure. Always start at the first red action, since that's your root cause. The Analytics tabs give you a 30-day rolling view of run counts and errors.5. Inputs and outputs
Click any action in run history to see its Inputs and Outputs sections. Inputs show what the action received, meaning the data and configuration that went in. Outputs show what the action produced, the result. When something goes wrong, compare the Inputs to what you expected. If the Inputs look wrong, the problem is upstream, in whichever action fed this one bad data. If the Inputs look right but the Outputs are wrong, the problem is in this action's configuration. That's how you confirm the first red action is actually the root cause. Bad inputs send you upstream, and bad outputs keep you here.6. Configure run-after
By default, each action only runs if the previous succeeded. To send a notification when something fails, add a parallel branch from the action that might fail. On that branch, open Settings, then Run after, and switch from "is successful" to "has failed". You can tick additional conditions too, like has timed out or is skipped. Power Automate then draws a red dotted arrow above the branch, which is the visual cue to spot in your own flows. With this one flow, you've handled both outcomes, which is the first error-handling pattern you'll reach for in real ones.7. Resubmit and Compose
Two more troubleshoot levers are worth knowing, Resubmit and Compose. When a run fails, open it from run history and click Resubmit, and Power Automate replays it with the original trigger payload. Fix something, resubmit, and see whether it passes. It's the cheapest debugging loop in the platform. Compose is the second lever. When you can't tell what value an action is actually receiving, drop a Compose action between two steps with the expression you want to inspect. Save, test, and look at the Compose output in run history, then remove it. Treat Compose as a magnifying glass you drop in, read, and remove.8. Let's practice!
Now it's time to read run history, trace a failure, and see error handling in action.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.