vRO Debugger: How to Use Breakpoints and Watch Expressions

If you still debug Orchestrator code by adding System.log() lines everywhere, the built-in debugger can save you a lot of time. You can pause a workflow or action on any line, look at every variable at that moment, and even try out expressions while the run is paused. In this post, I’ll walk through it with a small bug.

Tested on: VCF Operations Orchestrator 9.1.1 (example code, Nov 2026) and vRealize Orchestrator 8.x (debugger screenshots and video, 2022).

Quick demo video

Here’s the whole process in one short video. The steps below explain each part.

Step by step

We’ll use an action that adds two numbers. The catch: because of a small mistake, one input is a number and the other is a string.

Step 1: Reproduce the bug

The first step in debugging is always finding a way to make the bug happen every time.

• Create an action with two inputs, number1 and number2.

• Add this code to the action script:

var sum = number1 + number2;
System.log(number1 + " + " + number2 + " = " + sum);

• Save the action and click Run.
• Enter 5 for number1 and 1 for number2.

• The log shows 51 instead of 6. That’s the bug we’re going to fix.

Step 2: Pause the code with a breakpoint

The usual way to debug a problem like this is to add a lot of System.log() or System.debug() lines and check the values as the script runs. That works, but breakpoints are faster. A breakpoint pauses your code in the middle of a run so you can look at every value at that moment. And you don’t have to edit and save the script each time you want to see something new.

To set a breakpoint, click the faded red dot to the left of the line number. It turns dark red, and the next debug run pauses on that line.

Step 3: Open the debugger

Important: For actions, the debugger only opens if the code has at least one breakpoint. For workflows, you can set a breakpoint inside a scriptable task, or on the item itself by clicking the small red box at its top-left corner:

• At the top, click Debug.

• A new Debugger tab opens in the bottom panel, with Watch expressions and Item variables.

• The run starts and pauses at the first breakpoint. The line where it’s paused shows a red star instead of a red dot .

Step 4: Step through the code and use expressions

Stepping lets you run your code one line at a time, so you can see exactly where it does something you didn’t expect. Use these buttons:

• Continue: runs until the next breakpoint, or to the end.
• Step Into: runs the current line. If the line calls a function, it goes into that function and keeps stepping there.
• Step Over: runs the current line, including any function it calls, without stepping into it.
• Step Return: finishes the current function and goes back to the line that called it.

• When you click Debug, Orchestrator suspends the run on the first breakpoint, var sum = number1 + number2;.
• Click Continue or Step Into to run that line, and check the value of sum.

The Watch expressions tab lets you keep an eye on values while you step. It isn’t limited to variables, you can enter any JavaScript expression. Try it:

1. Click the Watch expressions tab.
2. Click Click to add an expression.
3. Type parseInt(number1) + parseInt(number2).
4. Press . It shows parseInt(number1) + parseInt(number2) = 6.

So the numbers are right once they’re parsed, which means at least one of the inputs isn’t really a number. In our case, number2 is a string, so + joins the two values as text instead of adding them.

Step 5: Apply a fix

You don’t need to leave the debugger to fix it. Edit the script right there and run it again. Either change the number2 input type to number, or convert the values in the code:

var sum = Number(number1) + Number(number2);
System.log(number1 + " + " + number2 + " = " + sum); // 5 + 1 = 6

Things to watch out for

• No breakpoint, no debugger. For actions, Debug only works if there’s at least one breakpoint in the script.
• Watch out for + with strings. If either value is a string, + joins them instead of adding. String inputs from forms and REST calls are a common cause.
• Screenshots are from 8.x. The 9.x client may look a little different.

Wrapping up

That’s how you get started with the Orchestrator debugger. Once you get used to breakpoints and watch expressions, you’ll reach for System.log() a lot less, and you can test ideas right while the code is paused. See you in the next post.