I have often been writing about how to handle exceptions and get the correct and detailed error message, describing in an easy and clean manner the failures in our processes:
- Logic Apps: Catching errors
- How to get the Error Message with Logic App Try-Catch (Part I)
- How to get the Error Message with Logic App Try-Catch (Part II) – Using an Azure Function
- How to get the Error Message with Logic App Try-Catch (Part III) – Using a generic Logic App
- Logic App Best Practices, Tips and Tricks: #6 Error handling… configure run after settings
- Logic App Best Practices, Tips, and Tricks: #15 Get the error message
At some point, every integration process will fail. This can happen for many reasons. A change may not have been tested properly. An external system might be down or under maintenance. There could also be issues in Microsoft infrastructure. These are normal and expected scenarios in real‑world integrations.
When a failure occurs, one thing becomes critical: understanding exactly why it failed. In most cases, we can inspect the Logic Apps run history to identify the error and its cause. This works well, except in scenarios such as Stateless workflows on Logic Apps Standard, where run history is not available.
Even when a run history exists, relying on manual inspection is not ideal. In production environments, we usually want to log errors automatically. Common destinations include Application Insights, SQL databases, Event Hubs, or other monitoring systems. This logging must happen without human intervention.
To achieve this level of automation, we need access to the exact error message at runtime. Only then can we store meaningful diagnostic information and react quickly when something goes wrong.
📝 One-Minute Brief
Provides a practical guide on how to retrieve detailed error messages in Azure Logic Apps Consumption, helping diagnose failed runs by extracting hidden error information from actions and workflow outputs.
By default, Logic Apps let you handle errors at the per‑action level by using Configure run after settings. However, when you need more advanced control, you can instead use a Scope action and implement try‑catch or try‑catch‑finally patterns. In practice, this approach works well for structuring complex workflows and centralizing failure handling.
That said, getting a detailed error message in Logic Apps can still be challenging. For example, error information is often buried in action outputs, and it may vary depending on the workflow structure. As a result, you will find multiple ways to extract the same details at runtime. Each approach can work, but each one also comes with its own trade‑offs. Therefore, choosing the right strategy depends on your workflow complexity, logging requirements, and the level of reuse you want to achieve.
For those reasons, my teammate Luis Rigueira and I decided to create this 60-page, detailed whitepaper: Logic Apps Consumption – How to get the Logic App error detail message guide.
What’s in store for you?
In this whitepaper, we will be addressing some of the possible ways to address these needs, but also addressing some of the following questions:
- How can I implement error handling?
- This is an important question and topic because, without proper error handling, we cannot be able to send an automated request to retrieve the error message; instead, our workflow will complete that action in a failure state.
- What out-of-the-box features are available to capture and access error details?
- How can I improve these default features in a no-code, low-code way and in a code-first approach?
Where can I download it?
You can download the whitepaper here:
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
