How long sign-in lasts

A common question from IT teams reviewing First Six: how long does a session stay alive, and what happens when it ends? This page answers both, role by role.

At a glance

Who	Session length	How it extends
Student	30 days	Any activity within the window mints a fresh 30-day session
Staff	8 hours	Any activity within the window mints a fresh 8-hour session
Demo visitor	Bounded by the demo cohort's expiry	Activity does not extend

These numbers are platform-wide settings, and any institution can ask us to tighten them; nothing changes on your side. A per-institution window is something we'd scope with you rather than flip on the spot, because today the windows apply across the platform.

Why students and staff differ

Students are reaching for First Six between classes, at midnight when they're spiralling, on the bus to campus. Bouncing them to SSO every few hours is the wrong shape for a wellbeing companion they should treat like Spotify, not like their bank.

Staff see the help inbox and check-in sentiment data. A stolen staff session has a wider blast radius, so we keep the window short. Eight hours covers a normal working day; the rolling refresh means a staff member never gets bumped mid-task during that day.

How rolling refresh works

On every page the user loads, we check how old their session is. If it's more than an hour old (and still valid), we quietly mint a fresh one with the full role-appropriate window. The cookie in the browser updates in the background; the user notices nothing.

So:

• A student who opens First Six once a week sees no sign-in prompt for as long as they keep coming back at least once a month.
• A staff member who works a full nine-hour day sees no sign-in prompt. They signed in at 9am, the session rolled forward as they worked (at most once an hour, which is all it needs), and only expires 8 hours after they actually stop touching the app.
• A student who hasn't opened the app in 31 days is sent back through SSO on their next visit.
• A staff member who closes their laptop for the weekend is sent back through SSO on Monday morning.

What ends a session immediately

• Explicit sign-out. The "Sign out" link clears the cookie before the user reaches their next page.
• Session revocation from the console. Revoking someone's sessions ("log out everywhere", or deactivating a staff member from the Team page) takes effect on their next page load. This is the immediate cut-off.
• Disabling the identity at your IdP (Microsoft Entra, Okta, Google Workspace) stops any new sign-in immediately. An existing session, though, runs until its window lapses (8 hours of inactivity for staff, 30 days for students), so for an instant cut-off pair the IdP disable with a console revocation.
• Demo expiry. Demo cohorts have a hard server-side expiry. Once the cohort is over, the session ends mid-click and the visitor lands on the "demo ended" screen.

What ends a session automatically

A session ends silently, with a redirect to your institution's sign-in page, when:

• The cookie's signed token is past its expiry. Middleware catches expired tokens before any page renders so the user never sees broken data.
• The browser drops the cookie because it's been 30 days (student) or 8 hours (staff) since the last visit.

The user lands back on whatever page they tried to open after they re-auth, so the interruption is one extra click and zero lost context.

What we don't do

• We don't auto-extend sessions for users who aren't actively touching the app. The rolling refresh requires a page load. An open tab in the background doesn't keep the session alive indefinitely.
• We don't offer a "Remember me" toggle. The default is already generous for students, and a per-user toggle would muddy the institution-wide policy IT teams want to be able to state plainly.
• We don't auto-sign-out on idle within the window. Inactivity timers (the Blackboard / Workday pattern) make sense for gradebooks and finance tools. First Six is neither.

If you need different numbers

Email your account contact. Nothing changes on your side. Today the windows are platform-wide settings, so a tighter number is a change we make and ship for the platform; a genuinely per-institution window is something we'd scope with you first.