Debugging

The visual debugger lets you pause a function on the dev stand at any statement, see exactly which icon it’s paused on, and inspect every variable currently in scope — the same way you’d step through code in a text IDE, but directly on the diagram.

Setting breakpoints

• Right-click any statement icon (an action, a log, a loop, a call to another function, …) and choose Add breakpoint. A hollow red dot appears at the icon’s corner.

• Breakpoints are saved in your browser and belong to you, not to the project — they aren’t exported, published, or seen by other people working on the same project.

• You can toggle a breakpoint at any time, including while a debug session is already running: the dot fills in solid once a session picks it up.

Starting a session

Open the Dev menu in the toolbar and choose Debug (next to Run function). If the function takes parameters, you’ll be asked for them first, the same as with Run function. If you haven’t set any breakpoints yet, the session pauses immediately on the function’s first statement — otherwise it runs until the first breakpoint it hits.

Only one dev execution runs at a time: starting a debug session stops whatever the dev stand was previously running, the same rule Run already follows.

Running and debugging a trigger function

A trigger function normally starts when its event arrives (a Telegram message, a webhook call, …). To run or debug one on the dev stand without waiting for a real event, open it and choose Run function or Debug in the Dev menu: a dialog asks for the test payload — the event the trigger would deliver, as JSON. The editor checks it against the trigger’s payload type (e.g. a Telegram message) and underlines what doesn’t fit; a payload that isn’t valid JSON or doesn’t match the type is not sent. The first time the dialog offers a skeleton of the type, after that the last payload you ran the function with (remembered in this browser); Reset to sample brings the skeleton back.

Schedule triggers need no payload — they start with the current time, the same as a scheduled run.

While paused

• The paused icon is highlighted on the canvas, and the view pans to it if it’s off-screen.

• The side panel lists every variable in scope at that point — function parameters, everything declared earlier in the current function, and loop variables if you’re paused inside one.

• Continue resumes until the next breakpoint (or the function finishes).
• Step over resumes until the next statement at the same call depth — it won’t stop inside a function called from the current line, only after it returns.
• Stop ends the session outright.

Things to know

• Debugging only works on the dev stand — a published (prod) version is never instrumented, so a live production workflow can’t be paused or inspected this way.

• A debug session left paused for a long time may find its dev pod has been put to sleep in the meantime (the same idle scale-down that applies to an idle dev stand generally). The execution itself isn’t lost — it’s durable — but the first click after a long pause can be slow while the pod wakes back up.