Why This Is Useful
Most Apex debugging is people sprinkling System.debug() everywhere, saving, re-running, reading a wall of log, adding more debug statements, and repeating until they find it.
It works. It’s also slow, and you always forget to take half of them out afterwards.
The Apex Replay Debugger gives you what developers on every other platform take for granted: real breakpoints, stepping through line by line, and inspecting actual variable values at each point. No debug statements required.
It’s been around a while, but it used to be a pain: download logs from your org, drag them into your project by hand, then run it. I rarely bothered. That’s changed, and now VS Code can pull logs into your project automatically, which makes the whole thing genuinely usable.
Step 1: Turn On Debug Logging From VS Code
You don’t need to touch Setup for this any more.
Ctrl+Shift+P → SFDX: Turn On Apex Debug Log for Replay Debugger
That creates a trace flag for you with the right log levels, which is the bit people usually get wrong by hand. It lasts 30 minutes.
If you need logs for a different user (say you’re debugging something only they can reproduce), you’ll still want Setup → Debug Logs → New and trace their user instead.
Step 2: Do The Thing That Breaks
Go and reproduce your problem. Save the record, click the button, run the anonymous Apex, whatever it takes.
Then come back and run:
Ctrl+Shift+P → SFDX: Get Apex Debug Logs
You’ll get a list of recent logs with timestamps and sizes. Pick yours and it downloads straight into a .sfdx/tools/debug/logs folder in your project.
Step 3: Set Breakpoints And Replay
Open your Apex class and click in the gutter to the left of a line number, exactly as you would in any other IDE. Red dot appears.
Then, with the log file open:
Ctrl+Shift+P → SFDX: Launch Apex Replay Debugger with Current File
Now you get the full debugger experience:
Variables panel – every variable in scope and its actual value at that moment.
Call stack – how you got here, which is enormously useful in an org with a trigger framework and six layers of service classes.
Step controls – step over, step into, step out, continue.
The word “replay” is doing real work in that name, by the way. You are not debugging live. You’re stepping through a recording of something that already happened. You can’t change values or take a different branch. But you can see exactly what everything was at every point, which is what you actually needed.
The Log Analyzer Is Worth A Look Too
While you’re here, the Salesforce Extension Pack includes an Apex Log Analyzer that gives you a visual flame chart of your transaction.
Open a downloaded log and you get a timeline showing what ran, in what order, and how long each bit took. It’s the fastest way I know to find out why something is slow, because the expensive thing is just… visibly the widest block.
Pair it with the limit checks from my general debugging post and you can usually find a CPU timeout culprit in a couple of minutes.
Things That Will Catch You Out
Your log got truncated. Logs cap at 20MB. If your breakpoint is past the truncation point it will never hit. Turn every log category down to NONE except Apex Code, and set that to FINEST.
The trace flag expired. Thirty minutes goes quickly. If no new logs appear, that’s usually why.
Wrong user traced. Async work runs as the Automated Process user, so a Queueable or Change Event trigger won’t show up under your own trace.
Your local code doesn’t match the org. The debugger maps the log onto the files in your project. If somebody deployed a change you don’t have locally, your breakpoints land on the wrong lines and everything looks insane. Retrieve before you debug.
Worth The Setup?
Genuinely, yes. The whole thing is three commands you’ll have memorised after a week, and it replaces most of the debug-statement-shotgun approach.
The place it really earns its keep is unfamiliar code. When you’ve inherited an org and something goes wrong six layers deep, being able to see the call stack and every variable at each level beats reading code and guessing by a very wide margin.
Salesforce’s own Replay Debugger documentation has the full detail if you want it.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
