Is there a way to adjust the various logging levels when deploying code to production through the IDE? The log is being truncated and I'm not seeing error details that are preventing my deployment.

Or should I use a Change Set and then set a log on my user using Setup -> Monitoring -> Debug Logs?


3 Answers 3


The Debug Log Filters are defined in the Metadata API, but only for use when executing code or running tests, they sadly are not present as a deployable aspect. In terms of what your wanting to do, with a large number of classes. I wanted to do something recently to focus Debug Filter settings on a handeful of classes from a large set.

Basically I disabled at the top level all filtering and enabled for each class what I wanted, this seemed to work quite well for what I wanted. Here is what I did.

  1. Go to Monitoring > Debug Logs
  2. Click New and provide your User
  3. Next to the entry created for your user click Filters
  4. Switch everything to NONE and click Save

Then on the few classes that you do want logging for

  1. Go to Develop > Classes
  2. Click on the class
  3. On the Log Filters tab, click the Override checkbox
  4. Set the settings to what you want.

NOTE: I found the UI's for both the above steps to be a little flakey, so go back in each case and double check your settings have taken.

Hope this helps!


You can adjust the logging level per class & trigger (that might mean A LOT of stupid clicking). Go to the class in Setup, last tab is called "log filters" and reduce the noise coming from the biggest culprits.

Metadata API itself indeed exposes to you some options (check this PDF, page 23) but I have no idea how would you use the same from the IDE.

logType Optional. The debug logging level for running tests. The default is None. Valid options are:
• None
• Debugonly
• Db
• Profiling
• Callout
• Detail

So unless you have just a handful of classes that spam the log - consider using the Migration Tool?

  • Thanks for your reply. There are over 600 managed and unmanaged classes alone in the instance. This would be a good project to send to an offshore outfit ...
    – David
    Dec 5, 2012 at 20:46
  • 1
    If you have a spare sandbox (full one if you suspect it's data issue although unit tests should create their own data...) you could always refresh it, deploy there, run all tests and watch how the hell unleashes :/
    – eyescream
    Dec 5, 2012 at 20:53

As far I know debug logs will monitor any API and Internal communications that will happen with in the sandbox/Prod but never heard about any tool to monitor/specifically say what could be failing. The only failure reason that can be extracted is the error message that you can see why the deploy failed when you try through eclipse (or) change set. would be interesting to know if someone would disagree !!!

You must log in to answer this question.

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