Use debug logs to track events that occur in your org. Debug logs are generated when you have active user-based trace flags, when you run Apex tests, and when executed code or API requests include debugging parameters or headers.
|Available in: both Salesforce Classic and Lightning Experience|
|Available in: Performance, Unlimited, Developer, Enterprise, and Database.com Editions|
The Salesforce user interface, Email Services, and Approvals are not available in Database.com.
|To use the Developer Console:||“View All Data”|
|To execute anonymous Apex: ||“Author Apex”|
|To use code search and run SOQL or SOSL on the query tab:||“API Enabled”|
|To save changes to Apex classes and triggers:||“Author Apex”|
|To save changes to Visualforce pages and components: ||“Customize Application”|
|To save changes to Lightning resources:||“Customize Application”|
A debug log can record database operations, system processes, and errors that occur when executing a transaction or running unit tests. Debug logs can contain information about:
- Database changes
- HTTP callouts
- Apex errors
- Resources used by Apex
- Automated workflow processes, such as:
- Workflow rules
- Assignment rules
- Approval processes
- Validation rules
The debug log does not include information from actions triggered by time-based workflows.
The system generates a debug log every time a transaction that is included in the defined filter criteria is executed.
Transactions can be generated from the following:
- Salesforce user interface
- executeanonymous calls
- Web services
- Email services
The filter criteria set for the user, the Developer Console, or the API header determine what is included in the debug log.
Debug logs don’t include transactions that lead conversion triggers. For example, suppose that a converted lead triggers a workflow rule. The debug log doesn’t show that this workflow rule fired.
The following are examples of when to use a debug log.
- As a developer creating a custom application, you can use the debug log to validate the application’s behavior. For example, you can set the debug log filter to check for callouts. In the resulting debug log, you can view information about the success and duration of those callouts.
- As an administrator for an org, you can use the debug log to troubleshoot when a user reports difficulty. Set a trace flag on the user, ask the user to step through the problematic transaction, and then use the debug log to view the system details.
Debug Log Limits
The following are the limits for debug logs.
- 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 org can retain up to 50 MB of debug logs. Once your org has reached 50 MB of debug logs, the oldest debug logs start being overwritten.
Debug Log Truncation
To provide the most pertinent information, debug logs are truncated, usually starting with older log entries. The newest log entries are always preserved. 200 KB of the debug log are deleted when the log reaches its maximum size of 2 MB.
The following events are necessary for processing the debug log, so they’re not deleted during truncation.
Log entries for events that are necessary for processing the debug log aren’t truncated. However, other log information that appears between the start and end lines of these log entries is removed during log truncation.