Every session has an idle timer that resets on activity. When the user goes idle for longer than the configured maximum, their session is invalidated and they're forced to log back in. That's the primary defence against unattended-device risk — someone walking away from their desk, closing the lid of their laptop without locking it, leaving a session live in a browser tab forever.
The setting lives at Site Settings → Session → Maximum Session Idle Time, and it's expressed in seconds. The default in the shipped configuration is 1,209,600 seconds — exactly two weeks. That's deliberately generous: it's a value that suits consumer apps where convenience trumps strict security. For business apps, you'll typically want to bring it down significantly.
What counts as activity
Any HTTP request that includes the session cookie resets the idle timer. That includes:
- A page navigation (clicking a link, submitting a form).
- Any AJAX call the page makes — saving a row, loading a dropdown, fetching a notification count.
- A polling request from the platform's real-time poller (if Polling is enabled).
- Any browser background tab that's open and periodically pinging the server.
That last point is important: a user with the platform open in any background tab will not appear idle even if they're nowhere near the screen. Apps that include client-side polling effectively never auto-log-out their users while the tab is open. If you need stricter behaviour, combine the idle time with a separate "hard timeout" via custom JS that logs the user out after N minutes of no mouse/keyboard activity.
Picking a value for your app
Three concrete recommendations based on different app types:
- Banking, healthcare, payment processing — 900 seconds (15 minutes). Conventional in regulated industries. Some standards (PCI-DSS in particular) mandate timeouts in this range.
- Internal business apps — 14,400 seconds (4 hours). Long enough that a typical working session doesn't get interrupted, short enough that a desk left for a long meeting will require re-authentication.
- Consumer apps — 1,209,600 seconds (2 weeks). Conventional for B2C — users get frustrated if they have to log in again every visit.
You can also segment by surface. If your platform has both an admin panel and a customer portal, consider a tighter idle time for admin sessions and a looser one for portal sessions. That's typically configured via custom code (the underlying setting is global) but it's worth implementing for any app where admins handle sensitive data.
Coordinating with Always Check Session
The idle timeout is enforced regardless of Always Check Session. When that setting is off, the timeout is checked at request time using the session cookie's age; when it's on, the timeout is checked against the session's last-activity timestamp in the configured store. The effective behaviour is the same — only the implementation differs.
What the user sees when they time out
Their next request after the timeout returns to the login page rather than completing. If they were in the middle of filling in a long form, they'll typically lose their unsaved input. To avoid that frustration for users with high-value forms (UIVs, complex Custom Forms), consider implementing client-side draft-save logic that persists in-progress form data to localStorage on every change.
Tip: Test your chosen idle time with a real user workflow before going live. A 15-minute timeout that interrupts the typical user's day every few hours quickly becomes a major source of support tickets and lost work.
Note: Both Always Check Session and IP/User-Agent verification operate independently of the idle time. You can have a long idle time but short revocation latency, or a short idle time but no per-request session lookups — they're orthogonal levers.