Using Miraxa to Debug and Explain Failed Runs

Ask Miraxa to investigate why a run failed, explain a feature in the context of the page you are on, and suggest ways to make a workflow run faster and cheaper.

Overview

When a run does not do what you expected, you usually face two questions: what went wrong, and what should you change. Miraxa, the intelligent layer across your automation in Spojit, answers both. Miraxa is the chat surface available on every page, and it can read the execution history of the workflow you are looking at. Instead of reading raw step output yourself, you can ask a plain-language question like "Why did my last run fail?" and get back the failing node, the reason it stopped, and a concrete fix you can apply on the canvas.

Because Miraxa knows the page you are on and the workflow you are editing, it grounds every answer in your actual setup: your trigger type, your Connector nodes and the exact tools they call, your variables, and the error a step returned. The same surface that builds and edits workflows also explains them, so you can move from "this run failed" to "here is the corrected node" without leaving the Workflow Designer. This guide covers three jobs Miraxa is good at: investigating a failed run, explaining a feature in context, and tightening a workflow so it runs faster and costs fewer credits.

Before You Start

  • Open the workflow that produced the run you want to investigate, or open its run in execution history first, so Miraxa has the right context.
  • Have at least one completed run to point Miraxa at. A workflow that has never run gives Miraxa nothing to investigate.
  • Open Miraxa from the chat surface on any page. In the Workflow Designer it can also act on the canvas for you.

Steps

Step 1: Investigate why a run failed

Open the workflow whose run failed, then ask Miraxa a direct question such as "Why did my last run fail?" or "Which node stopped my most recent run and why?". Miraxa reads the execution history for that workflow and tells you which node failed, what error it returned, and which input was involved. For example, it can tell you that a Connector node calling create-order on your e-commerce connector failed because a required field was empty, or that a find-documents call returned nothing so the downstream step had no data to work with.

If you are not sure which run to look at, ask Miraxa to "summarize the last few runs of this workflow" and it will point you at the ones that failed. You can then drill in with a follow-up like "Show me what the Transform node received before it failed."

Step 2: Trace the cause back to a node and a variable

Once Miraxa names the failing node, ask it to explain the chain that led there. Useful follow-ups include "What value did {{ order.total }} have when the Condition node ran?" or "Why was the input to the Send Email node empty?". Miraxa traces variables back through the steps that produced them, so you can see whether the real problem is an upstream step that returned the wrong shape rather than the node that actually errored.

This is especially helpful when a step succeeds but produces unexpected output. Asking "Why did the Loop node only run once?" or "Why did {{ input.subject }} come through blank?" turns a confusing run into a specific, fixable cause.

Step 3: Ask Miraxa to apply the fix

In the Workflow Designer, Miraxa can act on the canvas, not just describe the fix. After it identifies the cause, ask it to make the change: "Add a Condition node that checks if {{ order.total }} is over 100 and connect the true branch to a Send Email node", or "Update the Connector node so the email field maps to {{ input.from }}." Miraxa can add, delete, update, and connect nodes for you. If your instruction is ambiguous, for example if it is not clear which node a new node should connect to, Miraxa asks you first before changing anything.

After Miraxa scaffolds the change, open the node and confirm the details in the properties panel, then use the Run button to re-run and verify the fix.

Step 4: Explain a feature in the context of the page you are on

Miraxa knows which page you are on, so you can ask "what does this do" questions and get an answer about your actual setup rather than a generic definition. On a Connector node, ask "What is the difference between Agent Mode and Direct Mode?" and Miraxa explains both, then tells you which one this node is using and whether that is the right choice. On a Knowledge node, ask "What does a Transient collection do here?" and it explains it in the context of your run.

This works anywhere in Spojit: on the approvals inbox, on a trigger configuration, or while reading execution logs. Ask "What does this error mean?" while looking at a failed step and Miraxa explains the error in plain language and what typically causes it.

Step 5: Find ways to make a workflow run faster and cheaper

Miraxa can also look at a workflow and suggest ways to reduce both run time and credit cost. Ask "How can I make this workflow run faster and cheaper?" and it reviews your nodes for common opportunities: switching a predictable Connector node from Agent mode to Direct mode so it stops spending AI credits on a deterministic single-tool call, running independent steps inside a Parallel node instead of one after another, or tightening an Agent mode prompt and adding a Response Schema so the model does less work.

Be specific to get the best suggestions. "This Connector node just calls get-order every time, can I make it cheaper?" lets Miraxa recommend Direct mode directly, and it can convert the node for you on the canvas if you ask.

Tips

  • Name real things in your prompt. Referencing the actual node type, connector, tool name, and variables with {{ }} gives Miraxa precise context and a sharper answer than a vague "why is this broken".
  • Open the right workflow or run first. Miraxa grounds its investigation in the page you are on, so pointing it at the failed run before you ask saves a round trip.
  • Scaffold with Miraxa, then fine-tune in the properties panel. Let it make the structural change on the canvas, then confirm field-level details yourself.
  • Use a follow-up to dig deeper. After the first answer, ask Miraxa to trace a specific variable or step rather than re-asking the whole question.

Common Pitfalls

  • Asking before there is a run to investigate. A workflow that has never executed has no history for Miraxa to read, so investigate after at least one run.
  • Assuming the failing node is the root cause. The node that errored is often downstream of the real problem. Ask Miraxa to trace the variable back to the step that produced it.
  • Vague prompts get vague fixes. "Make it better" gives a broad answer. State the node, the goal, and the variable you care about.
  • Applying a canvas change without reviewing it. Miraxa asks first when an instruction is ambiguous, but you should still confirm the node in the properties panel and re-run before you rely on the fix.

Related Articles

Learn More

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.