Power Automate Error Code Lexicon: The Most Important HTTP and Connector Errors

A flow turns red, the run history shows an error code like 403 or an internal name like ActionFailed, and the error message itself doesn't really help you move forward. That's exactly where the searching begins: is it a problem with the connection, the input data, or the target service? Without a reference, every single failure costs valuable time, because you first have to find out what the code even stands for.

This lexicon summarizes the most important HTTP status codes and the typical Power Automate-specific error names, as documented in the official error code reference for cloud flows from Microsoft. For each error you get a short explanation of what it means, the most common causes behind it, and where to look first. Simply look up the code that's currently showing up in your run history.

HTTP status codes at a glance

Many connector errors in Power Automate are ultimately classic HTTP status codes returned by the API being called. Microsoft lists the most common ones in the documentation on connector integrity:

• 400 Bad Request: The server cannot or will not process the request because the input data is invalid.
• 401 Unauthorized: Authentication failed, valid credentials are missing.
• 403 Forbidden: An API rate limit was exceeded or the permission is missing.
• 404 Not Found: The called operation no longer exists or has been marked as deprecated.
• 409 Conflict: The request conflicts with the current state of the target resource, often resolvable by resending after a correction.
• 415 Unsupported Media Type: The content type of the request is not supported by the server.
• 429 Too Many Requests: The API rate limit has been reached.
• 500 Internal Server Error: An unexpected error on the server side.
• 502 Bad Gateway: A problem with the hosting web server, often a closed connection.
• 504 Gateway Timeout: The server does not respond in time.
• 522, 523, 524: Connection or timeout errors, usually caused by a target service that is unreachable or overloaded.

Good to know: errors in the 400 range are almost always caused by the request itself, while errors in the 500 range point to a problem on the called service's side and can usually only be resolved by waiting or retrying.

Connection and authentication errors

This group of errors occurs when the flow can no longer log in to a connected service.

• InvalidConnection: The connection reference points to a connection that has been deleted, expired, or interrupted. Open the flow, select the affected action, and recreate the connection.
• ConnectionNotConfigured: An action requires a connection, but none has been selected, often after importing from a solution. Select the appropriate connection in the action.
• ConnectionAuthorizationFailed: The connection exists, but its stored credentials are no longer valid, for example because a password was changed or an OAuth token expired after 90 days of inactivity. Go to Connections, select the affected connection, and use Fix connection.
• Unauthorized (401): The authentication token is invalid or expired. Also check the sign-in logs in Microsoft Entra ID for blocks caused by conditional access.
• Forbidden (403): The user or the app is not allowed to perform the operation. The most common cause is a DLP policy blocking the connector in the environment, or missing permissions on the target resource.

According to Microsoft's documentation, it's worth switching production flows to a service principal connection, because it does not expire when an employee changes their password or leaves the company.

Connector and API errors

These errors come from the called service itself, not from Power Automate.

• ActionFailed: A generic error message meaning that an action has failed. The actual cause is in the action's output text; open the failed run and expand Outputs.
• BadRequest (400): The input data is incorrectly formatted, for example a string where a number is expected, or a required field is missing from the request body.
• NotFound (404): The referenced resource, such as a SharePoint list or a mailbox folder, was renamed, moved, or deleted.

For all three errors, the same first step helps: open the failed run in the run history and compare the inputs with the format that's actually expected.

Design-time and expression errors

These errors show up either when saving or only at runtime, when an expression is evaluated.

• InvalidTemplate: A syntax error in an expression, often mismatched parentheses or an incorrect action name.
• FlowCheckerError: The flow checker found a validation problem, usually an empty required field or a missing connection.
• DuplicateActionName: Two actions in the same flow internally share the same name, often after copying and pasting without renaming.
• MissingRequiredProperty: A required field in an action or the trigger was left empty.
• ExpressionEvaluationFailed: An expression cannot be evaluated at runtime because the actual data doesn't match the expression, for example accessing a field of an empty object. A `coalesce()` safeguard usually fixes this.
• ContentConversionFailed: The flow could not convert data from one type to another, for example a date in an unexpected format.

Timeout and throttling errors

This group occurs as soon as a flow exceeds time or volume limits.

• ActionTimedOut: A single action exceeded its configured time limit; the default timeout for an HTTP action is 100 seconds.
• OperationTimedOut: A long-running operation such as an approval or a webhook exceeded the maximum wait time. According to the documentation, cloud flows run for a maximum of 30 days.
• WorkflowRunActionRepetitionQuotaExceeded: A loop such as "Apply to each" exceeded the maximum number of iterations, often due to nested loops without prior filtering.
• FlowRunQuotaExceeded: The daily limit of action executions for the user or flow has been reached, depending on the license tier.
• DirectApiAuthorizationRequired: The flow uses a premium connector, but the triggering user does not have a matching license.

How to proceed systematically

Instead of googling every error individually, a fixed sequence helps, as also described by Microsoft in the guide Troubleshoot cloud flow errors:

• Open the failed run in the run history and identify the action marked in red.
• Expand Inputs and Outputs for the action to see the exact status code and error message.
• Match the code to the appropriate category from this lexicon: connection, request, expression, or timeout.
• If you can't find the error text in this overview, copy it verbatim and search for it in the Power Automate Community forums, where almost all special cases have already been discussed at some point.

If a flow at your company regularly gets stuck on the same error codes, or if you can't pin down the cause even with this reference, we'll take a look together as part of our Power Automate consulting. As digital employees, we set up connections, error handling, and retry logic properly once and document them so that you keep control over your flows afterward.

Frequently asked questions

What's the difference between an HTTP status code and an error like ActionFailed?

HTTP status codes like 401 or 404 come directly from the called service and describe why the specific request failed. Errors like ActionFailed, on the other hand, are a generic wrapper from Power Automate, behind which one of these HTTP codes is almost always hiding. Open the outputs of the failed action to find the actual status code behind it.

Why am I getting a 403 error even though my credentials are correct?

A 403 doesn't necessarily mean incorrect credentials, but rather missing permission for the specific operation. The most common causes are a data loss prevention policy blocking the connector in your environment, missing write access to the target resource, or an exceeded API rate limit. First check the permissions on the target resource, then the DLP policies in your environment.

How do I find out which action caused an error?

Open the affected flow, select the failed run from the list of recent runs, and look for the red warning icon. You can expand the affected action, where the Inputs and Outputs sections show the exact status code and the original error message from the called service.

Is it worth fixing every error yourself right away?

For one-off HTTP errors like a 429 or 502, simply retrying is usually enough, because the cause lies with the external service and is temporary. If the same error occurs repeatedly, however, it's worth setting up structured error handling in the flow, for example with retry policies and a defined fallback action, instead of manually restarting it every time.

Do these error codes also apply to desktop flows?

The codes described here apply to cloud flows. For desktop flows that run on your PC, Microsoft maintains a separate reference titled Handling desktop flow errors, since different error sources such as UI elements or local applications play a role there.