Salesforce debug logs can be both a great tool, and a giant headache at the same time. On one hand, you can learn quite a bit about how the org is behaving during run time. On the other hand, you can’t
*** Skipped 1399744 bytes of detailed log
which is kind of a problem, but eventually we found some workarounds by
*********** MAXIMUM DEBUG LOG SIZE REACHED ***********
… ugh, RUDE! 😒
So what do you do when your debug session reaches 2MB faster than the Tesla Model S hits maximum torque? There are only a few options:
- File a Salesforce case, wait a bit, and they will temporarily increase the limit for the org.
- Reduce the log level detail for the user you’re debugging.
- Trace flag the noisiest classes into submission 💪.
- Wait for Salesforce to release streaming apex log support (safe harbor?).
Option 1 works if you don’t mind waiting for the case. Option 2 is OK if you just need to see a stack trace or crash details. But if the error doesn’t cause an exception, you’ll need Fine logging on Apex to see methods or variables.
With Option 3, you make the most of your debugging dollar by excluding classes from the debug logs. For example, let’s say you’re debugging a page, and the log is flooded with calls to some helper class.
Well, you can go to the Debug Log page, create a new Trace Flag (at the top), and specify one of the offending classes. Create a debug level of “None”, picking None for each of the drop-downs. Rinse and repeat for any of the classes you don’t want crowding your debug log.
And voila, your next debug log will contain that much less filler!
I’m still 🤞 for Option 4 though…