When an automation scenario run fails, you can now get a plain-language explanation of what went wrong and what to try next, right in the error panel.
Errors are part of building automations, especially when apps, APIs, and data fields converge in a single workflow. See what an error means in everyday language and decide what to try next, right where you are working, so you can keep building momentum on your scenario.
Introducing the new Error Explanations with AI functionality in Make. Now available in the output error panel for every organization and every plan.
Click the Explain error button on any error, whenever you want it, to get an AI-generated explanation of what happened, plus possible fixes based on the error in your scenario. Nothing changes until you click, and an Original message link lets you switch back to the raw error any time.
What’s new with Error Explanations with AI
-
Get the meaning behind the message, on your terms: Click Explain error to turn technical output, such as HTTP codes, API messages, and JSON errors, into a plain-language explanation you can act on, then switch back to the original message any time with one click.
-
See possible fixes in context: Review suggested next steps directly in the error panel, then update the affected module without leaving your scenario.
-
Find the right place to look: For a missing URL or required parameter, the explanation points you toward the field, value, or request that needs attention.
-
Keep scenarios moving: In earlier testing, scenarios with an explanation were reactivated about 20% more often after an error.
Who it’s for
Error Explanations with AI in Make save real time for teams handing off finished scenarios, especially to non-technical clients or teammates who get intimidated by raw error logs. Instead of walking someone through an HTTP code, point them to Explain error and let the plain-language version do the explaining.
Power users who prefer to read the raw output themselves are covered too. The raw error message is what shows by default, and Explain error only appears as a button you can choose to click. Just don’t click it and keep working with the original technical error message.
Put Error Explanations with AI to work
-
Check an HTTP request: A 404 response can indicate that the URL points to an example site rather than an order. Use the suggested steps to add the real order URL, replace a placeholder ID, and test with a known working value.
-
Fix a data mapping issue: When a required parameter is missing, go straight to the field that needs a value before the next run.
-
Keep clients moving: Agency builders can review an explanation with a client or teammate, agree on the next change, and get a client workflow active again, no technical translation required.
Errors are part of building. Now they’re a little easier to work through.
Happy automating! 
Valery from Make
Helpful resources
Fix errors and warnings
Introduction to errors and warnings
5 Likes
Great addition Valery!
This will save a lot of time, especially when handing off completed scenarios to non-technical clients who get intimidated by raw error logs.
Quick technical question: does the AI engine also analyze custom error payloads returned inside the body of an HTTP module (e.g., when an API returns 200 OK but has { "error": true } in the JSON), or does it currently trigger only on native Make execution failures?
Looking forward to testing this out on client builds!
3 Likes
Great idea for generic users that are not technical and would rather see plain text explanations. Also the suggestions on how to resolve this would cut down on a lot of threads here in the community.
But for power users, can we get a setting to disable this? I would prefer to just see the original error message and decide for myself on how to handle it.
2 Likes
Great question, happy to clarify: you stay in full control of how you view errors!
Nothing changes automatically. The raw error message is still there by default. Explain error is a new button you click on demand, per error, whenever you want the plain-language version.
And if you do click it, you’re not locked in either: there’s an Original message link right next to the explanation that takes you straight back to the raw error output whenever you want.
So there’s no need for a separate setting, since you’re already deciding for yourself every time, error by error.
Thanks for flagging this, @Stoyan_Vatov , I’m updating the post now to make that clearer for everyone else too! Valery
2 Likes
Hi Gabriele, thanks for the great question!
The explanation is generated from the error a module actually produces, so it triggers on genuine execution failures rather than on the response body. A 200 OK is treated as a successful run, so a custom payload like { "error": true } in the JSON won’t surface an explanation on its own.
The workaround is to add a validation step right after the HTTP module that finishes with an error when it detects that condition. Once the scenario actually errors out there, Explain error can help with it, and the context for the explanation is enhanced with the modules that ran before the failing one, so the HTTP response carrying that flag is taken into account too.
Looking forward to hearing how it goes on your client builds!
Jakub, from the team behind the implementation
2 Likes
thanks jakub, that clarifies it completely!
yeah handling APIs that return a 200 OK with { "error": true } inside the body is a super common headache on client builds, especially when clients try to figure out why a flow silently stopped. adding a validation router right after the HTTP module to throw an explicit error will definitely save us a lot of debugging time.
appreciate the quick breakdown!
2 Likes
