The Apex Replay Debugger works from a log file captured after execution. Nimbus debugs live - set a breakpoint, run your test, step through code as it executes. No org, no log download, no replay setup. VS Code and IntelliJ both supported.
Full side-by-side: Nimbus vs the Apex Replay Debugger.
A replay debugger works from a pre-recorded log. To use it, you need to:
A live debugger runs your code and pauses it at breakpoints as it executes.
Click the gutter in VS Code or IntelliJ to set a breakpoint. Nimbus pauses execution at that exact line - in triggers, service classes, test methods, anywhere.
Step through code one statement at a time without descending into called methods. See how values change as each line executes.
Step into a method call to debug its internals. Follows calls into service classes, utility methods, trigger handlers - your full call graph.
Finished inspecting a method? Step out returns to where it was called and resumes normal stepping from there.
See all local variables in scope at the paused line - primitives, SObjects, collections, class instances. Expand nested objects to any depth.
The call stack shows exactly how execution reached the current line - which method called which, with line numbers. Click any frame to inspect its scope.
Install the Nimbus extension from the VS Code Marketplace. Once installed, the extension connects to the Nimbus daemon running in your project and enables breakpoints, step controls, and variable inspection in the built-in Debug panel.
To start a debug session: open any test class, set a breakpoint by clicking the gutter, then use the Run & Debug panel or press F5. Select the test method to debug from the picker and Nimbus launches the interpreter with debugging enabled.
Coverage gutter decorations update automatically after each run - green for covered lines, red for uncovered, directly in the editor margin.
// .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Nimbus: Debug Test",
"type": "nimbus",
"request": "launch",
"test": "${input:testMethod}",
"stopOnEntry": false
},
{
"name": "Nimbus: Debug Current Test",
"type": "nimbus",
"request": "launch",
"test": "${file}",
"stopOnEntry": false
}
],
"inputs": [
{
"id": "testMethod",
"type": "promptString",
"description": "Test to debug (ClassName.methodName)",
"default": "AccountServiceTest.testCreateAccount"
}
]
}Install the Nimbus plugin from the JetBrains Marketplace. The plugin integrates with IntelliJ's built-in debugger UI - the same interface you already use for Java debugging, now working with Apex.
Set breakpoints by clicking the gutter. Right-click any test method and choose Debug with Nimbus, or use the debug run configuration. The Variables panel, call stack, and stepping controls all work as expected.
The plugin also adds a Nimbus tool window with a test tree, coverage visualization, and quick access to run or debug individual tests without leaving the IDE.
<!-- Run configuration (saved in .idea/runConfigurations/) -->
<component name="ProjectRunConfigurationManager">
<configuration name="Debug AccountServiceTest"
type="NimbusDebug"
factoryName="Nimbus Debug">
<option name="testPattern"
value="AccountServiceTest.testCreateAccount" />
<option name="stopOnEntry" value="false" />
</configuration>
</component>A test is failing with an unexpected null. Instead of adding System.debug() calls and redeploying, you set a breakpoint and step through the logic directly.
public class AccountService {
public static Account createWithDefaults(String name, String industry) {
Account acc = new Account(Name = name);
// ← Set breakpoint here to inspect 'acc' before the condition
if (industry != null) {
acc.Industry = industry;
} else {
acc.Industry = getDefaultIndustry(); // ← Or here, to step in
}
insert acc;
return acc;
}
private static String getDefaultIndustry() {
// Step in here to see what's returned
CustomSetting__c cs = CustomSetting__c.getOrgDefaults();
return cs?.Default_Industry__c; // ← Is this null?
}
}Variables
└── acc: Account {
│ Name: "Acme Corp",
│ Industry: null, ← not set yet
│ Id: null
│ }
├── name: "Acme Corp"
└── industry: null ← passed as null
Call Stack
AccountService.createWithDefaults line 4
AccountServiceTest.testCreate line 12Variables
└── cs: CustomSetting__c {
│ Default_Industry__c: null ← root cause
│ }
// CustomSetting not seeded in test setup.
// Fix: add to nimbus.properties:
// nimbus.seed.org-default.CustomSetting__c=
// Default_Industry__c=TechnologyLive debugging is the default. But when a test only fails in CI, or you want to inspect a run you already have, Nimbus can replay a recorded trace through the same debugger UI — and step backwards.
This is not the Apex Replay Debugger. There is no org, no log download, no checkpoint dance. You record a trace once, locally, then scrub the captured execution forwards and backwards with real breakpoints, the call stack, and variable panels. Nothing re-runs, so it is instant and perfectly deterministic.
Record at verbose or higher so statement-level steps are captured, then launch a replay session. Step back, reverse-continue to a breakpoint, or scrub to any line. A trace recorded below verbose has nothing to step through, and replay says so plainly instead of hanging.
// 1. Record a trace
// nimbus test "CalculatorTest.*" \
// --trace --trace-level verbose
// 2. Replay it in the debugger
// .vscode/launch.json
{
"name": "Nimbus: Replay last trace",
"type": "nimbus",
"request": "launch",
"mode": "replay",
"traceFile": ".nimbus/traces/…/trace.jsonl"
}
// stepBack + reverseContinue are enabled
// in replay sessions.Live breakpoints in VS Code and IntelliJ. No org, no log files, no replay setup. Set a breakpoint and run - that's it.