Elevated session counts after upgrading to Tokyo / Utah / VancouverIssue If an instance is recently upgraded to Tokyo, or Utah, or Vancouver, administrators may notice elevated session counts on the performance dashboard, stats.do or xmlstats.do This is due to a previous problem fix in Tokyo (PRB1570283/KB1504401 - When unauthenticated/guest session hits the timeout manager the session is updated with the property's integration session timeout) that is being reviewed. ReleaseTokyo, Utah, Vancouver.Cause1) The increased sessions were caused by a change made in Tokyo for PRB1570283.2) After Tokyo, xmlstats.do transaction sessions time out after 30 min of inactivity. The XMLStats sessions now pick up the guest session timeout of 30 minutes - Out of the box). 3) Before Tokyo, xmlstats.do transaction sessions use to time out just after 1 min of inactivity using the "glide.integration.session_timeout". 4) The elevated session counts are not actual user logged-in sessions. These are coming from ServiceNow monitoring (/xmlstats.do transactions) and last for 30 minutes for each session. 5) You can check the actual logged-in sessions through stats.do on multiple nodes: Logged in sessions: 8 (481 active)Logged in sessions: 6 (412 active) 6) Above active counts are xmlstats.do sessions + logged-in user sessions which seem to be too many at any time. 7) Most likely this will not have any impact on the instance, unless the instance already has memory issues and has hundreds of sessions on its production nodes. 8) If a production instance is affected, lowering the guest session timeout "glide.guest.session_timeout" or adding more nodes will resolve the issue. Having more sessions but no impact is not a reason to add more nodes. Support will evaluate if there is an actual impact on the customer instance before adding nodes if any.Related LinksViewing user and session details: https://docs.servicenow.com/bundle/tokyo-now-intelligence/page/administer/user-exp-analytics/task/view-user-sessions-log.html