|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 determines what is included in the debug log.
Debug logs don’t include transactions that are triggered by lead conversion. For example, suppose a converted lead triggers a workflow rule. The debug log won’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, then in the debug log, view information about the success and duration of those callouts.
- As an administrator for an organization, you can use the debug log to troubleshoot when a user reports difficulties. You can monitor the debug logs for the user while they step through the related transaction, 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
In order to provide the most pertinent information, debug logs are truncated starting with the oldest log entries. The newest log entries are always preserved. The debug log is truncated by 200 KBytes when it reaches its maximum size of 2 MB.
The following events are necessary for processing the debug log and are associated with non-deletable log entries:
Log entries for events that are necessary for processing the debug log don't get truncated and will always be part of the debug log, but other log information that appears between the start and end lines of these log entries is removed as part of log truncation.