SF Debug Viewer XGuides › Find SOQL & limit hotspots

Find SOQL, DML & governor-limit hotspots in a debug log

"Too many SOQL queries: 101" almost always means a query is running inside a loop. A debug log holds the answer — you just need to surface the counts and see which method is firing the queries. Here's how to find the hotspot.

Open SF Debug Viewer X →

Track down the hotspot in 3 steps

  1. Check the stats bar first. Load the log and read the totals — SOQL, DML, methods, exceptions, line count and duration — to confirm how close you are to a limit.
  2. Filter to SOQL (or DML). Turn off the other event types so the tree shows only queries, in execution order, with the method that issued each one.
  3. Look for repetition. The same query repeated many times under one method is the classic loop-query pattern. Use search and highlights to pin the offending call, then jump to the raw line to confirm.
SF Debug Viewer X with the call tree filtered to SOQL events and a stats bar showing query counts

Why this works

Honest scope: SF Debug Viewer X surfaces the counts, ordering and the method behind each event so you can locate the hotspot fast — fixing it (bulkifying the query, moving it out of the loop) is still a code change on your side.

Frequently asked questions

How do I find which SOQL queries caused a governor-limit error?
Read the SOQL/DML counts in the stats bar, then filter the call tree to SOQL events to see each query in order and the method that issued it. The same query repeated under one method is the usual cause of "Too many SOQL queries: 101".
Can the viewer show how many SOQL and DML statements ran?
Yes — the stats bar reports totals for methods, SOQL, DML and exceptions for the whole run.
How do I spot a slow method in the log?
Use the execution duration plus the timing-gap toggle and the call tree, and filter out noise like system methods and variable assignments so the expensive calls stand out.

Related guides

Open SF Debug Viewer X →