# Diagnosing and fixing SyteLine session timeout errors > Source: https://netray.co/erp-help/syteline-mongoose-session-timeout-error > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything. ## Kind error ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module Session / Connection Management ## Query SyteLine session has timed out please log in again error ## Alternate Queries - SyteLine keeps logging me out - CSI session timeout every few minutes - SyteLine IDO session expired error - SyteLine web client session timeout too short ## Applies To SyteLine 9.x, CloudSuite Industrial (CSI) 10.x, both .NET smart client and web (Mongoose) client ## Steps ### Find and adjust the right timeout layer **Items:** Note whether the timeout happens on the .NET smart client, the web client, or both - the smart client uses the IDO Data Service session, the web client also depends on the IIS session and any front-end load balancer. For the .NET client and IDO service, check the session timeout setting on the IDO Data Service (in IIS, under the IDO Data Service application, or in the SyteLine Server Configuration if using a service-based deployment). For the web client, check the ASP.NET session timeout in the web.config for the Mongoose Web (or CSI Web UI) application, and the associated application pool's idle timeout in IIS. If the environment is CloudSuite hosted (multi-tenant or single-tenant AWS), the timeout may sit at Infor's load balancer/ingress layer - open a support ticket with Infor if on-prem settings are already correct and the session still drops early, since customers cannot change that layer directly. Check for any reverse proxy, VPN, or corporate firewall with its own idle-connection timeout (common at 15-30 minutes) sitting between users and the SyteLine servers - this is a frequent, overlooked cause for users on VPN. Confirm client-side keep-alive or polling settings are not disabled - some SyteLine web client configurations rely on periodic background calls to keep the IDO session alive, and browser extensions or aggressive tab-suspension can block them. After adjusting a timeout value, restart the relevant IIS application pool (not just recycle) to ensure the new value is picked up, and test with a session left idle for slightly longer than the old timeout to confirm the fix. ## Sections ### The layered nature of SyteLine session timeouts **Body:** SyteLine's architecture means a 'session' is not one thing. The .NET smart client authenticates and holds an IDO session against the IDO Data Service (an IIS-hosted service). The web client additionally has its own ASP.NET session and, in CloudSuite deployments, sits behind Infor-managed load balancers with their own idle timeouts. A user reporting 'I keep getting logged out' could be hitting any one of these, and the fix is different for each. The practical diagnostic is timing: if the session drops at a very consistent interval (e.g. exactly 20 minutes of inactivity every time), that is a strong signal of a specific configured timeout rather than a network blip. If it is inconsistent, look at network infrastructure (VPN, proxy, wifi drops) instead of application settings. ### On-prem: where the settings actually live **Body:** For on-premise SyteLine, the IDO Data Service timeout is typically configured through IIS Manager on the application server, in the IDO service's web.config (sessionState timeout value) or via SyteLine's server configuration utility depending on version. The web client (Mongoose Web / CSI Web UI) has its own separate web.config sessionState entry and its own application pool idle-timeout setting in IIS - these two values are independent and should generally be set consistently to avoid a client session outliving its IDO session (which produces confusing 'session expired' errors mid-task). **Code:** - - - REM IIS application pool idle timeout is set separately in IIS Manager - REM Application Pools > select pool > Advanced Settings > Idle Time-out (minutes) ### CloudSuite / hosted considerations **Body:** In CloudSuite Industrial multi-tenant or AWS single-tenant deployments, customers do not have direct access to the load balancer or ingress timeout settings - these are managed by Infor. If on-prem-style settings (where accessible) are already correctly configured and sessions still drop earlier than expected, the next step is an Infor support ticket referencing the exact idle time observed, since it may require a change on Infor's side rather than the customer's. ## Pitfalls - Changing only the IIS application pool idle timeout without also updating the ASP.NET sessionState timeout - the shorter of the two still wins. - Assuming a CloudSuite hosted timeout can be changed the same way as on-prem - it usually requires an Infor support request instead. - Overlooking corporate VPN or firewall idle-connection timeouts, which can cut a session well before any SyteLine-configured value is reached. - Setting timeouts extremely long as a workaround, which increases the number of concurrently held IDO sessions and can affect license/session counts and server memory. - Not restarting (recycling alone is often insufficient) the IIS application pool after a web.config change, leading to inconsistent behavior across users hitting different worker processes. ## Ai Angle ERPray grounded on a customer's SyteLine environment can pull the actual configured timeout values from IIS/web.config documentation the team has stored, cross-reference them against a user's reported drop time, and tell an admin within one exchange which layer (IDO service, web session, or infrastructure) is the likely culprit, instead of the admin walking through all three by hand. ## Faq ### Why does the smart client time out but the web client does not, or vice versa? **Answer:** They use different session mechanisms - the smart client depends on the IDO Data Service session timeout, the web client additionally has its own ASP.NET session and IIS app pool idle timeout, so the two can be configured to different effective durations. ### Can I set the timeout to never expire? **Answer:** It is not recommended. Idle IDO sessions consume server resources and, depending on your licensing model, can hold a concurrent session slot. Extend the timeout to a reasonable value instead, such as 30-60 minutes. ### Does a VPN disconnect look the same as a session timeout error? **Answer:** Often yes to the end user, since both produce a 'please log in again' style message. Check whether the timing correlates with VPN idle-disconnect policy before changing SyteLine settings. ### Is the CloudSuite session timeout configurable by the customer? **Answer:** Generally no for the load balancer/ingress layer in hosted CloudSuite environments - that is managed by Infor. Application-level settings you do control should be checked first. ## Search terms syteline session timeout, syteline session has timed out, syteline keeps logging out, csi web client timeout, ido data service session timeout, syteline iis session config, mongoose web session expired, syteline cloudsuite session drop --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json