What we’re building
We will not build anything permanent here. We pick a ready-made workflow, step through a simulated run, then make one node fail to see what the workflow does about it. Boxes on the path the run takes light up in order. A failure follows the error path you chose for it, and boxes on other paths stay dark.Try it
Use the playground below. Pick a workflow from the Preset list, then:- Choose Linear and press Step three or four times. We watch each box light up in turn, from the trigger to the terminal. Run plays the same steps on its own and Reset starts over.
- Choose Error route. Shift-click the
HTTP_REQUESTnode, or press its Fail button in the table under the graph, then press Run. You should see the run leave that node on itserrorport and reach the alert terminal, while the boxes of the normal path stay dark. The run still ends in success, because we gave the failure somewhere to go. - Choose Approval, make the
LLM_CALLnode fail and press Run. You should see the failure follow that node’serroredge to the dead-letter terminal, and the approval and update steps stay dark.
What the simulation leaves out
Stuck? If nothing lights up, press Run or Step first: the graph is idle until a run starts. If a node will not fail, check that its Fail button in the table reads “Will fail”.
What you just did
We stepped a simulated run through three workflows and broke a node on purpose in two of them. A failure does not stop the whole workflow: it leaves through theerror port of the node, and whatever we connected there takes over.
Where to go next
Your first workflow
Install Yukta and run a real workflow in ten minutes.
How failure works
Retries, error routes, failure budgets and join rules: what a real run adds.
How Yukta works
Nodes, edges, ports and messages.
Examples on GitHub
Ready-to-run workflows for CI, data, alerts and agents.