Apex Developer Guide
jNewer Version Available
Debug Log
- Database changes
- HTTP callouts
- Apex errors
- Resources used by Apex
- Automated workflow processes, such as:
- Workflow rules
- Assignment rules
- Approval processes
- Validation rules
You can retain and manage the debug logs for specific users, including yourself, and for classes and triggers.
To view saved debug logs, from Setup, enter Debug Logs in the Quick Find box, then select Debug Logs. When you’ve started retaining debug logs, you can view, download, or delete your logs from this page.
- Each debug log must be 2 MB or smaller. Debug logs that are larger than 2 MB are reduced in size by removing older log lines, such as log lines for earlier System.debug statements. The log lines can be removed from any location, not just the start of the debug log.
- Each organization can retain up to 50 MB of debug logs. Once your organization has reached 50 MB of debug logs, the oldest debug logs start being overwritten.
Inspecting the Debug Log Sections
After you generate a debug log, the type and amount of information listed depends on the filter values you set for the user. However, the format for a debug log is always the same.
- Header
- The header contains the following information.
- The version of the API used during the transaction.
- The log category and level used to generate the log. For example:
- The following is an example of a
header.In this example, the API version is 25.0, and the following debug log categories and levels have been set.
Apex Code DEBUG Apex Profiling INFO Callout INFO Database INFO System DEBUG Validation INFO Visualforce INFO Workflow INFO - Execution Units
- An execution unit is equivalent to a transaction. It contains everything that occurred within the transaction. The execution is delimited by EXECUTION_STARTED and EXECUTION_FINISHED.
- Code Units
- A code unit is a discrete unit of work within a transaction. For example, a trigger is one unit of code, as is a webService method, or a validation rule.
- Units of code are indicated by CODE_UNIT_STARTED and CODE_UNIT_FINISHED. Units of work can embed other units of work. For
example:
- Units of code include, but are not limited to, the following:
- Triggers
- Workflow invocations and time-based workflow
- Validation rules
- Approval processes
- Apex lead convert
- @future method invocations
- Web service invocations
- executeAnonymous calls
- Visualforce property accesses on Apex controllers
- Visualforce actions on Apex controllers
- Execution of the batch Apex start and finish methods, as well as each execution of the execute method
- Execution of the Apex System.Schedule execute method
- Incoming email handling
- Log Lines
- Log lines are included inside units of code and indicate what code or rules are
being executed. Log lines can also be messages specifically written to the debug log.
For example:
- Log lines are made up of a set of fields, delimited by a pipe (|). The format is:
- timestamp: consists of the time when the event occurred and a value between parentheses. The time is in the user's time zone and in the format HH:mm:ss.SSS. The value represents the time elapsed in milliseconds since the start of the request. The elapsed time value is excluded from logs reviewed in the Developer Console.
- event identifier: consists of the specific event that triggered the debug log being written to, such as SAVEPOINT_RESET or VALIDATION_RULE, and any additional information logged with that event, such as the method name or the line and character number where the code was executed.
- Additional Log Data
- In addition, the log contains the following information.
- Cumulative resource usage is logged at the end of many code units, such as triggers, executeAnonymous, batch Apex message processing, @future methods, Apex test methods, Apex web service methods, and Apex lead convert.
- Cumulative profiling information is logged once at the end of the transaction and contains information about the most expensive queries (used the most resources), DML invocations, and so on.
Setting Debug Log Filters for Apex Classes and Triggers
Debug log filtering provides a mechanism for fine-tuning the log verbosity at the trigger and class level. This is especially helpful when debugging Apex logic. For example, to evaluate the output of a complex process, you can raise the log verbosity for a given class while turning off logging for other classes or triggers within a single request.
When you override the debug log levels for a class or trigger, these debug levels also apply to the class methods that your class or trigger calls and the triggers that get executed as a result. All class methods and triggers in the execution path inherit the debug log settings from their caller, unless they have these settings overridden.
The following diagram illustrates overriding debug log levels at the class and trigger level. For this scenario, suppose Class1 is causing some issues that you would like to take a closer look at. To this end, the debug log levels of Class1 are raised to the finest granularity. Class3 doesn't override these log levels, and therefore inherits the granular log filters of Class1. However, UtilityClass has already been tested and is known to work properly, so it has its log filters turned off. Similarly, Class2 isn't in the code path that causes a problem, therefore it has its logging minimized to log only errors for the Apex Code category. Trigger2 inherits these log settings from Class2.
-
Trigger1 calls a method of Class1 and another method of Class2. For
example:
-
Class1 calls a method of Class3, which in turn calls a method of
a utility class. For
example:
-
Class2 causes a trigger, Trigger2, to be executed. For
example: