System Log
The System Log is the developer-facing debug log inside the Salesforce Developer Console that captures everything happening on the platform during a single Apex execution, from SOQL queries to DML operations to flow steps.
Definition
The System Log is the developer-facing debug log inside the Salesforce Developer Console that captures everything happening on the platform during a single Apex execution, from SOQL queries to DML operations to flow steps. Each entry is timestamped and tagged with the type of activity (USER_DEBUG, SOQL_EXECUTE, DML_BEGIN, METHOD_ENTRY, LIMIT_USAGE_FOR_NS), giving developers a turn-by-turn replay of what the platform did and how much of the governor budget each step consumed.
System Log refers specifically to the live log view inside the Developer Console. The same captured records appear as ApexLog rows in the data model and can be downloaded, queried, or exported through the Tooling API. Most developers use the System Log tab interactively (open the console, run Anonymous Apex, watch the log appear in real time), while ops teams pull the ApexLog records into external observability tools when they need to investigate production issues offline.
How the System Log captures, filters, and surfaces every line of Apex execution
What gets logged
Salesforce captures execution events in nine categories: Apex Code, Apex Profiling, Callout, Database, System, Validation, Visualforce, Workflow, and Wave (Tableau CRM). Each category has a log level (NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST). Setting Apex Code to FINEST gives line-by-line execution; Database to FINEST gives every SOQL with the bind parameters and the row count returned. Each combination of category and level controls which events the platform writes during the next Apex run, and the result lands in the System Log when you replay it.
Trace flags and log retention
Logging is governed by Trace Flags. A trace flag sets the log categories and levels for a specific user (or for the running anonymous code) and an expiration time. Trace flags expire automatically after 24 hours unless renewed. The captured logs are retained for 7 days, capped at 250 MB per user. Once the cap is hit, new logs overwrite old ones. The Developer Console makes this invisible by managing trace flags for you when you toggle the Logs panel, but in production with many users you sometimes need to manage trace flags by hand to keep the cap from rolling over the logs you care about.
Filtering and the search bar
The System Log surfaces logs with three controls. The first is the search box at the top: type any string and it highlights every line that matches. The second is the Filter button, which scopes by log event type (User Debug only, SOQL only, DML only). The third is the Execution Tree view, which groups lines by method and shows the call stack with cumulative time and limit consumption. Real-world debugging usually combines all three: filter to USER_DEBUG, search for the variable you logged, then expand the surrounding method to see the SOQL and DML around it.
Limit consumption tracking
Every Apex transaction ends with a LIMIT_USAGE_FOR_NS block showing the final counts: SOQL queries used, SOQL rows returned, DML statements, DML rows, future calls, CPU time, heap, callouts, and email invocations. The block appears at the very bottom of the log. This is the single most useful entry in the System Log because it tells you exactly which governor limit your code is consuming the most of. Optimization work starts with reading this block, identifying the dominant counter, and tracing back through the log to the line that drove it up.
User Debug and the System.debug call
System.debug() is the basic developer tool for printing values into the log. Every call writes one USER_DEBUG line tagged with the requested level. A common pattern is System.debug(LoggingLevel.ERROR, accountId) to surface a variable at ERROR level so it stands out from FINE chatter. The System Log shows USER_DEBUG entries in green, which makes them findable in a wall of platform-internal lines. In production code, System.debug calls should be removed or wrapped in a feature flag because they cost CPU time and clutter the log for the next developer who reads it.
Execution Tree and method timing
The Execution Tree view in the System Log shows the call hierarchy: a top-level trigger or controller action, every method it calls, every method those methods call, the time each one took, and the limit usage attributable to each branch. This is the right view for performance debugging because it shows where the CPU time is going. A method that takes 2 seconds of a 10-second transaction is your optimization target; a method that takes 50 ms can be left alone. The view also exposes hidden recursion in trigger handlers where a method appears multiple times in the tree.
Pulling logs out of the platform
For observability beyond the console, ApexLog records are queryable through the Tooling API. The query returns log metadata (user, length, operation, application) and the log body is fetched separately via a REST endpoint. Customers who route logs to Splunk, Datadog, or New Relic build a scheduled Apex job that pulls new ApexLog records, posts the bodies to an external endpoint, and deletes the platform-side copies. The platform-side 7-day retention is too short for forensic work, which is why external archiving matters for any org with serious operational scale.
Capture a System Log to debug an Apex failure
Open the Developer Console, set the right log levels, reproduce the failing action, and read the resulting System Log to find the root cause.
- Open the Developer Console
Setup, Developer Console (or the gear icon, Developer Console). The console opens in a new window with several tabs at the bottom.
- Open the Logs panel
Click the Logs tab at the bottom. The panel lists recent logs for your user, sorted descending by timestamp.
- Set log levels
Debug, Change Log Levels. For most debugging, set Apex Code to FINEST, Apex Profiling to FINEST, Database to FINEST, and the rest to INFO. Save.
- Reproduce the failure
Take the action that triggers the bug: save the record, run the report, click the Lightning button. The platform captures the log automatically and appends it to the Logs panel.
- Open the log
Double-click the new log row. The System Log opens with the captured execution. Tabs at the top let you switch between Raw Log, Execution Tree, and Limits views.
- Read the LIMIT_USAGE_FOR_NS block
Scroll to the bottom of the Raw Log. Find the LIMIT_USAGE_FOR_NS block. Note the dominant counter, then trace back to the line that drove it up. That line is your starting point for the fix.
Per-category setting (NONE through FINEST). Higher levels produce more detail but consume the 250 MB cap faster.
Time-boxed log directive scoped to a user, class, or trigger. Expires automatically; renew if a longer investigation is needed.
Hierarchical view of method calls with timing and limit usage per branch. Best view for performance work.
Programmatic access to captured logs. Used for export to external observability tools.
- The 250 MB per-user log cap rolls over silently. If you reproduce a bug at high log levels and then run other work, the original log can be overwritten before you save it.
- Trace flags expire in 24 hours. A long investigation needs renewed flags or you stop capturing logs at the wrong moment.
- System.debug calls left in production code cost CPU time and inflate logs. Remove them before deploying or wrap them in a logging utility that respects an org-level flag.
- Log levels too high (FINEST everywhere) make the log unreadable and can themselves push the transaction over the 10-second CPU limit. Use FINEST only on the category you are investigating.
Trust & references
Cross-checked against the following references.
- System Log ConsoleSalesforce Developer Docs
- Debug LogSalesforce Developer Docs
- ApexLog Tooling APISalesforce Developer Docs
Straight from the source - Salesforce's reference material on System Log.
- System Log DocumentationSalesforce Developer Docs
- Debug Log LevelsSalesforce Developer Docs
- Apex Debugging ToolsSalesforce Developer Docs
Hands-on resources to go deeper on System Log.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the System Log?
Q2. What does it record?
Q3. Why is it essential?
Discussion
Loading discussion…