Jive Support Policy - Support Limitations Regarding Investigating Errors in Jive logs

Version 2


    Various types of logs are available in Jive, which can be useful in troubleshooting issues in the application. Jive Support will often gather or request logs that pertain to a specific component which is experiencing an issue. These logs will often include information that is related to an issue that is happening to an end user using the Jive platform.


    While Jive encourages our customers to provide relevant logs when filing a case, there have been situations where customers have requested a review of errors found in logs despite there not being any issues observed by end users. Jive support will not investigate these types of requests and will only analyze log files for issues that are directly tied to broken or unexpected functionality.


    The policy

    • Jive Support will utilize the various logging resources available to address and troubleshoot unexpected behavior within the Jive platform (this excludes customizations provided by Jive Partners or Jive Professional Services. These are addressed by the respective authors).
    • Jive Support will not provide an analysis for any logs without being clearly connected to an issue which is impacting your community. Errors in logs themselves do not impact your community.



    We appreciate when customers want to proactively address issues before there is a user impact, and logging errors can understandably raise a sense of alarm. In most contexts, the implication of an error message is that something is wrong. This is especially true when the majority of unexpected behavior in Jive usually casts errors to some form of logs. That said, it is important to understand that an ERROR exception is not always equal to something not working.


    Jive Support Case analysis has shown that of these requests, the vast majority do not result in any actionable findings.


    Example scenario:

    A user is trying to log into a Jive community that uses SAML SSO. They inadvertently provide the wrong credentials. The result of this is an ERROR level exception with a long stack trace which points to many different Java classes, many of which make sense for what the user did, some which do not because of the nature of the application stack.


    Does this error mean something is broken? Quite the opposite! It is necessary for the application to cast this error in order for authentication to fail. The failure then triggers a break in the login flow which causes a different set of code to be executed. This code tells the IDP and the user that the wrong credentials were used. This is one of many examples where an ERROR exception is necessary for normal behavior.