Whether you are an admin or support agent looking to troubleshoot something not working as expected, like records not saving or jobs failing, or you are a developer working to identify an issue with code, debug logs play an important role to get to the root cause of an issue.
Some of the useful information debug logs provide are:
Below is a collection of strategies and tactics I use to collect and debug logs, analyze them, and everything in between!
Collecting a debug log is easy, and there is more than one way to do so.
Be mindful that once you enable log collection for a user that several logs will begin to appear, which can make it tricky to know which one you are after. Pro tip: it is generally a good idea to enable logs right before an action is performed if it can happen on demand so you can start with a smaller list to scroll through.
Pro tip: it is generally a good idea to enable logs right before an action is performed if it can happen on demand so you can start with a smaller list to scroll through.
Sometimes performing a single action can generate a few logs as well. This can happen as components on a record detail begin to pull in fresh data immediately after the action is performed for example. A good strategy I generally find is to go for the logs that appeared first when the action was performed rather than the most recent one. Most of the time the log you want will be a larger one rather than one that is comparatively empty. Additionally, you can look at the Operation column which may have ”/aura” if you edited a record in lightning or “/RECORD_ID/e” in classic.
Now that you have the log, below are some handy search terms I use to quickly identify if there is a problem as well as some other issues that could arise. Although it is common to find the error toward the bottom of the log, it is important to note that the last thing to execute is not always where the problem occurred. In fact, I typically look at what precedes the error to get a better picture of what executed prior; whether it be a workflow field update, trigger, or flow. Here are search terms of keywords to look for in the debug log:
System.LimitException is a great example where the last thing to execute may not be the cause. For example, the SOQL query limit may be exceeded if triggers are firing multiple times as a cascade of down-stream triggers update related records (which is especially common in larger organizations having a lot of customization). In this scenario, it is not a bad idea to look for DML_BEGIN in the log to see if there are any updates that could have been avoided (unnecessary DMLs would likely cause additional triggers to fire and use up more SOQLs). Checking the updates can also rule out any sort of update loop such as a User / Contact sync trigger going back and forth endlessly.
Another good example is the Apex CPU time limit which could be caused by slow running code such as a long running callout or a global describe in an org with a lot of objects, especially if it executes more than once. Fortunately, it is easy to identify long running items by simply scrolling through the log while looking for any sudden jumps in the timestamp that appears to the left of each line in the log:
Sometimes the debug log may get too long. When this happens the log will be missing information and contain the line ”*** Skipped xxxbytes of detailed log”. Simply search for ”Skipped” though since the number of bytes skipped will vary. When this occurs you will need to edit the log Filters / Debug Level to reduce the amount of information collected and reduce the size of the log. For example, the ”System” category tends to generate a lot of lines that are not very useful so I might reduce that and any other categories I am not currently interested in.
For more troubleshooting tips, check out “Developer Console for Admins”, from Lead Consultant, Rachel Garton! The Developer Console pulls together development and debugging tools into one place, taking the troubleshooting features you already have and extending them.