Hi community,
While reviewing a client’s Service Center error logs, I noticed a high volume of "role required" exceptions. After investigating, these are almost entirely (if not all) tied to user session timeouts (users leaving a tab open, the session expiring, and then the user interacting with a role-protected screen/action).
As we know, the standard Global Exception Handler does not log Security Exceptions by default (the Log Error property is set to "No"), meaning these are being caught and logged directly by the platform's native error handling.
I am considering disabling the logging for these specific errors to reduce log noise, as outlined in this documentation article: https://success.outsystems.com/documentation/11/monitoring_and_troubleshooting_apps/disable_registered_role_required_error_logs/.
Before I do, I wanted to get the community's perspective:
1. Is there any compelling architectural, auditing, or security reason to keep allowing the platform to register these specific session-timeout role errors?
2. If disabled, is there a risk of blinding ourselves to legitimate unauthorized access attempts, or is there a better way to filter out just the session-related noise?
Any insights or best practices would be appreciated!
Hello Lucas FF Lopes ,
In most real-world OutSystems applications, these "role required" errors during session timeout are expected behavior and usually create more noise than value in logs. As per the OutSystems documentation, disabling the registration of these specific errors is acceptable when they are clearly related to expired sessions and not actual authorization issues. My recommendation would be: 1)Keep monitoring enabled for genuine Security Exception patterns. 2)Disable only the known session-timeout "registered role required" noise mentioned in the documentation. 3)Ensure the application properly redirects users to login/session expired screens to improve UX and reduce repeated exceptions. From an auditing/security perspective, real unauthorized access attempts should still be captured through authentication logs, audit mechanisms, or abnormal access patterns — so filtering these timeout-related entries generally does not reduce security visibility significantly. This approach keeps logs cleaner, improves monitoring signal quality, and aligns with OutSystems best-practice guidance/documentation. We implemented a similar approach in production environments and it helped reduce unnecessary log noise substantially without impacting security monitoring.
Thanks and Regards,Akshay Deshpande