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 defaults. Any institution can ask us to tighten them — we'll make staff 4 hours, or students 7 days, on request.

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, in plain terms

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 at every page load, 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.
• Account revocation. If your IT team disables the underlying institutional identity (Microsoft Entra, Okta, Google Workspace), the next page load fails to refresh the session and the user is bounced.
• 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. We can change either window per institution without a code change on your side, and the change takes effect from the next sign-in.