I am spending entirely too much time trying to figure out how to surface debug statements instead of debugging my actual code and I wanted to see if anyone out there has come up with a fool-proof solution. Here's what I've tried:

When adding a debug statement, I set the logging level:

System.Debug(LoggingLevel.INFO, 'For the love of god, show up in the log!');

Then I set debug filters, which can be done in two different places with different options:

UI Settings: enter image description here

Console Settings: enter image description here I'm not sure why there are two rows and I'm not sure what the Expiration means.

Also, the filtering options are different through the UI and Console. For instance, there is a 'None' option in the UI, but the least verbose setting in the Console is 'Error'. Because I've set 'None' in the UI, that shines through here on the Console, but if I were to edit those settings, I wouldn't have 'None' as an option. In any case, neither setting seems to be respected - here's the head from the debug log:

enter image description here

For the two places I know that I can add filters, I've set Apex Code to Info, but the head shows that I'm getting 'Apex_Code; Debug'. And I'm getting Info for nearly everything else where I should ideally get 'None' or worst case 'Error'. Whatever, right? But the problem is that my debug log reaches it's maximum size before it gets to the debug statements that have any meaning for me. Instead of debuging my code, I'm spending my day debugging Salesforce's debugging.

This has mostly been me complaining, but I do want to know, does anyone one know what's going on and how I can get the debugger to respect my filter settings?

  • What action are you performing to generate the debug log? I.e. Are you running anonymous Apex via a tool, using the standard Salesforce UI, calling an API? Mar 23, 2015 at 23:43
  • @DanielBallinger has a good answer but I know I use LoggingLevel.INFO and before I start a debugging session in DC, I set the two rows to the highest expiration time 11:30PM and then start my test. The debug log then honors the INFO level.
    – cropredy
    Mar 24, 2015 at 0:08
  • @DanielBallinger - I'm using Execute Anonymous.
    – cwarheit
    Mar 24, 2015 at 0:16
  • @cwarheit Are you doing this via the developer console or another tool? Mar 24, 2015 at 0:17
  • As a work around, I'm finding success using Execute Anonymous in Workbench. It allows me to explicitly set the Log Category and Level (and consistently honors those settings) - so I'm only returned Apex Code at the Info Level. That being said, Salesforce clearly has some work to do with debugging. Is a full debug log really that expensive that it needs to be limited??
    – cwarheit
    Mar 24, 2015 at 0:20

1 Answer 1


Here is the quick answer so you can hopefully get on with your day of debugging goodness.

Use Error rather than Info level logging.

System.Debug(LoggingLevel.Error, 'For the love of god, show up in the log!'););

You don't need to use "Set event filters for username" under Monitoring > Debug Logs > Filters. Just have the developer console open and set the ApexCode level to ERROR.

When you look at the Change Log Levels screen in the developer console what you are actually seeing is a UI over the TraceFlag records.

There are two records due to the two TraceFlag records that get created when the developer console is started. One will have the ScopeId set to the current User and the other will be empty for organization level logging. Note that it is also possible to create multiple traces for a single user, which results in multiple rows in the UI. Further rows can be created where the TracedEntityId is that of an ApexClass with LogFilter overrides (see below).

It might be worth checking for rogue records here. You can do this with SOQL in the Developer Console Query Editor by checking "Use Tooling API":

Select Id,IsDeleted,TracedEntityId,ScopeId,ExpirationDate,Workflow,Validation,Callout,ApexCode,ApexProfiling,Visualforce,System,Database from TraceFlag

You can safely delete them all (assuming you are the only dev in the org) and then let the developer console recreate them.

It would be worth checking if you have per Apex class logging level overrides on. This would appear under the Log Filters on the individual Apex Class.

enter image description here

If you are interacting with Salesforce via an external tool or the API it is possible the requests are overriding the logging levels. For instance, the DebuggingHeader in the older Apex API allows the logging levels to be explicitly set for that request.

As you found, Workbench offers the option to execute anonymous Apex with defined logging levels.

The FuseIT SFDC Explorer tool lets you explicitly define the logging levels that will be applied. (Full Disclosure: I work for the company that makes this tool)

Setting the Debug logging levels if the FuseIT SFDC Explorer

  • Although I may be mistaken I believe this question is more about how to ensure your debug levels are respected when generating debug logs in general, not so much how to make this one debug log appear. Mar 23, 2015 at 23:36
  • Yes, fair point. It's going to take some time to cover all the different ways logs can be generated. For instance, there are explicit headers on some of the APIs that override the logging levels for the request. Then there are the per Apex class overrides. The thought a short initial answer might be helpful. Mar 23, 2015 at 23:42
  • I had tried with LoggingLevel.Error and I didn't see my debug statements bubble up. I started in the developer console, didn't see my debug statements, then looked to see if there were any filters on my user in the standard Debug UI and on the involved triggers/classes. The triggers and classes didn't have any filters set on them, so I knew that wasn't a problem. Looking at the filters in the UI and in the Console - it looked like there were some conflicts so I started changing setting in one, then the other, and I couldn't get consistent results and neither would respect my changes.
    – cwarheit
    Mar 24, 2015 at 0:17
  • I suspect the best option would have been to delete all the problematic TraceFlag records. The developer console will be using the Tooling REST API executeAnonymous, which doesn't take explicit logging levels. Mar 24, 2015 at 1:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .