The Summer ’15 release notes have a section called Receive Debug Logs Predictably.

It currently states that the order of precedence for debug logs will be:

  1. Trace flags set in the Developer Console override all other logging logic.
  2. If you don’t have active trace flags, synchronous and asynchronous Apex tests execute with the default logging levels.
  3. If no relevant trace flags are active, and no tests are running, your API header sets your logging levels.
  4. If you enable system logs for a user, you get debug logs for that user’s next 20 requests.
  5. If your entry point sets a log level, that log level is used.

The order of points 2 and 3 seem a bit off to me.

If I explicitly set a DebuggingHeader on an API request I'd expect it to take precedence over the default values for synchronous and asynchronous Apex tests.

In fact, I'd expect an explicit DebuggingHeader to take precedence over a TraceFlag as well.

How can I control the logging level for test cases at the API call level without defining a TraceFlag? If I had to define the TraceFlag it will affect all logging for the given user.

IMHO, the following order would make more sense. All are based around excluding a previous match and the applicable record/header etc... being defined.

  1. The API DebuggingHeader header sets your logging levels for that transaction.
  2. TraceFlag for the user/class/trigger is used. This will apply when the Developer Console is actively logging, and for direct creation of TraceFlag records via the Tooling API
  3. If you enable system logs for a user, you get debug logs for that user’s next 20 requests.
  4. Synchronous and asynchronous Apex tests execute with the default logging levels.
  5. If your entry point sets a log level, that log level is used.
    I'm not 100% sure on the position of this last point. Apparently it is for Visualforce requests that include a debugging parameter. Does it make sense for a TraceFlag or system level user log to take precedence?
  • 1
    I was going to say that their order makes sense, then I realized that your ordering is much more sensible. I wonder if we'll get an official answer?
    – sfdcfox
    May 28, 2015 at 4:28
  • @sfdcfox Having a clearly defined order will be good, and I can see the appeal of starting with the developer console generated TraceFlags. I use API defined transaction logging levels all the time to run tests and it would be shame to lose that ability. That said, I haven't actually tested the documented order against a Summer 15 org yet, so it may just be the documentation. May 28, 2015 at 8:23

1 Answer 1


The ordering has been inconsistent and, in some cases, undefined. We wanted to make it consistent. The order here was the one that was used by most entry points.

Part of the long-term goal of the refactoring we are doing is to make it much less confusing as to what logs were generated and why. We get a lot of investigations due to misunderstanding of the various ways to generate logs and which of those ways takes precedence.

As of today, the DebuggingHeader vanishes after you've made your API call. It generates logs that don't reconcile with the persisted TraceFlag objects in the org. This, in turn, generates customer cases! (e.g., I have a traceFlag saying to log at this level, yet my log is being generated at that level. why?)

One simple solution is to make an API call prior to your request which creates the correct TraceFlag, in place of putting the same information in the DebuggingHeader. This will allow someone looking afterwards to understand what happened and how the log was generated.

We will be making more changes in this area in the coming releases to make this all more sensible and hopefully more flexible for everyone.

  • Thanks for coming back. Consistency is always a good thing. I do most of my testing and debugging via the API with a custom tool. Being able to change the logging per request without affecting the TraceFlag is really useful. IMHO, it would be confusing if a 3rd Party app starts changing the TraceFlag frequently outside the developer console. It kind of means the TraceFlag will replace all usage of the DebuggingHeader. Jun 2, 2015 at 19:29
  • One idea, maybe the first line of the debug log that indicates API version and logging levels could be updated to include what mechanism defined the levels. E.g. [TraceFlag:7tf10,,,1] or [DebuggingHeader] or [SystemLog:005...1]. Then the developer console or third party tool could indicate what was driving the logging levels for that transaction. Jun 2, 2015 at 19:32

You must log in to answer this question.

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