function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Debug Logs (Can we get more than 20? per user)

I'm developing in a Sandbox and it's really a pain to have to go to Setup > Monitoring > Debug Logs and then add the user or reset the user each time that I need to debug some piece of code.


Was there a particular reason for this change?


Is there any way to enable debug logs permanently, at least for the Developer/Sandbox organizations? 


We spend all day developing on but since the change in the way debug logs are activated it has been really difficult  to debug simple problems.





This limitation of 20 logs was always there.


As a workaround of this 20 logs, i create entries in a custom object, where i need to store debug information for some users. Just check that you do not touch governor limits while inserting these entries in the custom object.


First of all thanks GreatG for you prompt response. 


Maybe I was not clear enough. 


The limitation of 20 logs was always present in Setup > Monitoring > Debug Logs.


But, before Spring 10, you could in the page click on System Log and a pop up will open where all the logs related to the current window will be displayed without the need to open another browser to login as the Sys Admin going to setup and reseting the logs every 5 minutes.


This new behavior in Spring 10 is making the debugging of our applications a lot harder, and it's taking a lot more time that it used to take.


The custom object solution that you mention is too limited for us, it may be a possible replacement for System.debug but we don't just look at the output of System.debug we look at the entire log file looking for errors and possible optimizations.


Unless there is a good reason behind it, I think it will be logical to enable System Logs at least in the pop-up window by default for all Sandboxes/Developer Organizations, or at least giving the developer an option to leave it enabled. And the System Logs should be attached to all email notifying of unhandled exceptions.


From time to time a QE is testing the application and it get's an error but then is unable to reproduce the problem and we just receive an e-mail stating the line where the exception was thrown but we don't have the logs to see what actually happened and that information may be of use to try to narrow down the problem and attempt to reproduce it.


Isn't your purpose solves with "System Log"- it enables us to debug easily as we code.

Is there some specific reason that you want to retain the debug logs in excess of 20?

The reason why this was done to manage the multitenant environment else if everyone keeps on retaining their debug logs then will be so much space involved.

Each organization can retain up to 50 MB of debug logs. Once your organization has reached 50 MB of debug logs, the oldest debug logs start being overwritten.


Did this answer your question? if not, let me know what didn't work, or if so, please mark it solved.


Hi Ispita_Navatar,


Reason 1 (the most important): 

System Log doesn't solve the problem because in order to use system log we need to go to Setup > Monitoring > Debug Logs and enable the logs for the current user (and this can only be done with a System Administrator profile, so if we are doing QA with a user that's not system administrator we have to open another browser to log-in as SysAdmin and enable the logs every 5 mins.) 


If we don't enable the Debug Logs the System Log window only shows the logs for the code run as anonymous from that System Log window.


Reason 2:

Sometimes as the QE is testing the application he doesn't have the System Log window open all the time, if he find a bug and he is unable to reproduce it again, we don't have the System Log to see what actually happened.


It would be a lot easier to reproduce the bug if we got the System Log (at least the last few system logs) right now if we don't go to the Setup to enable them every 5 min. we loose this information. 


Reason 3:

Not directly related but still it will be an improvement At least when the application throws an unhandled exception and an email is sent the log could be attached to the email, we have found out that the log is only attached if once again we go to the setup every 5 mins to enable it.