Session timeout warning vs Exit warning vs Autosave form vs Permission denied state

Use session timeout warning when an authenticated session is approaching idle expiration, absolute expiration, device-lock policy, or required reauthentication and the user still has work or context to preserve.

Session timeout warning live example Exit warning live example Autosave form live example Permission denied state live example

Decision dimensions

Dimension	Session timeout warning	Exit warning	Autosave form	Permission denied state
UI or UX	UI + UX - Authenticated-session expiry and reauthentication boundary warning	UI + UX - Attempted-departure safeguard for unrecoverable in-progress work	UI + UX - Background-saving form progress	UI + UX - Authorization and access-boundary state
UI guidance	Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.	Show a warning only when the user attempts to leave with real unsaved, pending, failed, or unrecoverable work; place in-app route warnings at the point of departure with Save and leave, Discard and leave, and Stay editing choices.	Render a clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states.	Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
UX guidance	Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.	Use exit warning to interrupt an attempted departure that would lose work, context, payment state, upload progress, or session-bound data the product cannot safely recover.	Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button.	Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
Good UI	A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.	A grant form user clicks Back with two unsaved answers; a dialog names the changed section and offers Save and leave, Discard and leave, or Stay editing.	A long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp.	A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
Bad UI	The app logs out after 15 minutes with no countdown and clears a long form.	Every navigation shows Are you sure you want to leave? even after the form is saved.	A form removes the Save button and shows no save status, leaving users unsure whether typed answers are safe.	A denial page says Something went wrong and shows Retry even though the user lacks a required group.
Good UX	A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.	A user starts to close a tab after a failed autosave, sees the risk before leaving, stays on the page, retries the save, and then leaves without another warning.	A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable.	A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
Bad UX	A user returns from a phone call to find the form gone and a generic access denied page.	A user clicks a sidebar link after typing a long answer and loses it because the product only watched final Submit.	A user leaves after seeing an old saved message, but the newest field was never persisted.	The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
Best fit	An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.	Users have unsaved or pending changes that cannot be recovered if they leave.	Users spend meaningful time entering form content or application progress.	A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when	There is no authenticated session boundary and the issue is ordinary navigation away.	The page is clean, read-only, or all changes are safely saved and recoverable.	The form is short enough that a visible manual Save or Submit is clearer.	The user is not signed in and the next step is authentication rather than authorization.
Required state	Active session with no warning.	Clean state with no exit warning attached.	Initial state that explains progress will be saved automatically.	Whole-object access denied state.
Accessibility burden	Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.	Use a real dialog or alertdialog for in-app warnings, with a heading that names the loss risk.	Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states.	Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse	Using a client-only timer that disagrees with the server session.	Warning on every navigation regardless of whether work is dirty.	Removing the Save button while providing no autosave status.	Treating authorization denial as a generic retryable error.

Session timeout warning

UI or UX: UI + UX - Authenticated-session expiry and reauthentication boundary warning
UI guidance: Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.
UX guidance: Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.
Good UI: A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.
Bad UI: The app logs out after 15 minutes with no countdown and clears a long form.
Good UX: A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.
Bad UX: A user returns from a phone call to find the form gone and a generic access denied page.
Best fit: An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.
Avoid when: There is no authenticated session boundary and the issue is ordinary navigation away.
Required state: Active session with no warning.
Accessibility burden: Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.
Common misuse: Using a client-only timer that disagrees with the server session.

Exit warning

UI or UX: UI + UX - Attempted-departure safeguard for unrecoverable in-progress work
UI guidance: Show a warning only when the user attempts to leave with real unsaved, pending, failed, or unrecoverable work; place in-app route warnings at the point of departure with Save and leave, Discard and leave, and Stay editing choices.
UX guidance: Use exit warning to interrupt an attempted departure that would lose work, context, payment state, upload progress, or session-bound data the product cannot safely recover.
Good UI: A grant form user clicks Back with two unsaved answers; a dialog names the changed section and offers Save and leave, Discard and leave, or Stay editing.
Bad UI: Every navigation shows Are you sure you want to leave? even after the form is saved.
Good UX: A user starts to close a tab after a failed autosave, sees the risk before leaving, stays on the page, retries the save, and then leaves without another warning.
Bad UX: A user clicks a sidebar link after typing a long answer and loses it because the product only watched final Submit.
Best fit: Users have unsaved or pending changes that cannot be recovered if they leave.
Avoid when: The page is clean, read-only, or all changes are safely saved and recoverable.
Required state: Clean state with no exit warning attached.
Accessibility burden: Use a real dialog or alertdialog for in-app warnings, with a heading that names the loss risk.
Common misuse: Warning on every navigation regardless of whether work is dirty.

Autosave form

UI or UX: UI + UX - Background-saving form progress
UI guidance: Render a clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states.
UX guidance: Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button.
Good UI: A long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp.
Bad UI: A form removes the Save button and shows no save status, leaving users unsure whether typed answers are safe.
Good UX: A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable.
Bad UX: A user leaves after seeing an old saved message, but the newest field was never persisted.
Best fit: Users spend meaningful time entering form content or application progress.
Avoid when: The form is short enough that a visible manual Save or Submit is clearer.
Required state: Initial state that explains progress will be saved automatically.
Accessibility burden: Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states.
Common misuse: Removing the Save button while providing no autosave status.

Permission denied state

UI or UX: UI + UX - Authorization and access-boundary state
UI guidance: Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
UX guidance: Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
Good UI: A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
Bad UI: A denial page says Something went wrong and shows Retry even though the user lacks a required group.
Good UX: A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
Bad UX: The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
Best fit: A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when: The user is not signed in and the next step is authentication rather than authorization.
Required state: Whole-object access denied state.
Accessibility burden: Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse: Treating authorization denial as a generic retryable error.

Decision rules

Use session timeout warning when an authenticated session is approaching idle expiration, absolute expiration, device-lock policy, or required reauthentication and the user still has work or context to preserve.
Use exit warning when the user attempts to navigate, close, reload, sign out, or leave a surface with unsaved or unsafe work; the trigger is departure, not inactivity.
Use autosave form when the primary protection is continuous progress persistence that reduces the harm of timeout and can restore work after reauthentication.
Use permission denied state when the user is signed in but lacks the role, policy, group, share, or license needed for a resource or action.
A timeout warning should show remaining time, the consequence of expiry, and actions such as Stay signed in, Save draft, Finish now, or Reauthenticate.
Do not use a timeout warning as a vague security notice with no clock, extension action, preservation statement, or post-expiry path.
Warn earlier for high-effort tasks, assistive technology needs, long forms, uploads, payments, and public-device sessions where silent expiration causes loss or privacy risk.
When security policy requires logout, keep the warning honest: allow save or reauthentication only when allowed, and never imply the session can be extended past policy.
After timeout, route to reauthentication or signed-out state with work restoration when possible; do not present a generic permission or server failure message.
If autosave failed before the timeout, combine the warning with failed-save recovery instead of claiming the work will be preserved.

Inspect live examples

Session timeout warning Exit warning Autosave form Permission denied state

Failure modes

A user is logged out after inactivity with no countdown, loses a completed form, and cannot restore it after signing in again.
The warning says Session expiring soon but gives no remaining time, no extension action, and no statement about saved work.
Stay signed in resets only the client timer while the server session has already expired.
A timeout warning appears on every page load even when no authenticated boundary is near.
The product treats timeout as permission denied, sending users into request-access or retry paths that cannot restore the session.
A high-security session offers unlimited extension even though policy requires reauthentication or termination.