My company has created lots of computer software but one issue we have is with login timeouts.

Some developers want to make them shorter for security, while most users want it be infinite? Is there ever a justification to have no login timeout? How short is too short?

  • A lot of the annoyance of login timeouts can be mitigated by remembering (hashed) passwords, web apps are especially good at this since browsers do it for you, but that may not help in your situation.
    – Ben Brocka
    Sep 22, 2011 at 13:58
  • In my opinion an open tab/or page should not timeout. After the user leaves the page it can immediatly timeout.
    – Barfieldmv
    Sep 22, 2011 at 14:51

6 Answers 6


The length of the time out is partly dependent on the sensitivity of the data and security of the application.

For something like a banking site the time out needs to be quite short so that there is very little chance of someone getting access to the account if the user fails to log off.

For something like Facebook the time out can be longer - though even there I think there should be some time out as there is still sensitive information someone could get access to.

How short is too short? - if the user can't complete the most common actions within the time out then it's too short. For example, if you are reviewing your bank statement you need the data to be visible for a few minutes so you can mark off transactions etc. Any shorter and you'd have to refresh the page and could lose your place.

For your application you'll need to time common activities and make the time out a little longer than that.

  • 2
    Think also about the task performed. Sometime your user might need to fill in some information and then call someone, send an email or simply walk to somebody else's desk to fill in the rest of the information. Spend some time with the users and analyze this behavior, to see how many time is the appropriate time.
    – Pedro
    Sep 22, 2011 at 14:22
  • 1
    My bank logs me out after 5', which is too short for me, and worse, when I hit the 'back' button (Ok [ctrl]+left arrow). It annoys me greatly.
    – GUI Junkie
    Sep 28, 2011 at 20:22

The justification for login timeouts depends on the security level of your application and the how the users use the app. If your app handles financial/sensitive data, the login timeout should be short (logically), approx. 3-5 minutes.

If your app is a CMS, use a longer timeout. I would suggest approx. 45-60 minutes. This is to prevent content administrators from loosing content or content formatting if they are on the WYSIWYG editor screen for 30 minutes, which I frequently see.

In regards to justification for no timeout at all; I have one site that has a no login timeout. It is specifically for sales reps that always forget their passwords. This was a required feature by the client, not my normal best practice. Everyone has their specific needs and business objectives.

My strongest recommendation here is, know the audience. Make sure you understand what the users are doing and how long they are one a page on your site before setting up a login timeout.


In Web apps ( if you are referring to that) the timeout is reset everytime the server hears from you. this can lead to a user getting logged out even if he is using your site, reading, observing data, writing content etc. as long as he causes no new requests to be made.

Consider detecting user activity through mouse/keyboard/scroll events and triggering every x mins an ajax request to keep the timeout long. This will also enable you to set a shorter timeout, so that when the user finally leaves the computer, he is logged out fast. (if security is a concern)

  • Nice idea! I always thought it is impossible to know if a certain page tag is still open or not, but of course, via AJAX you can. And even if it stays open, but inactive, for some time, a re-login window could appear, just like a screensaver does.
    – giraff
    Sep 28, 2011 at 7:10

None of the answers submitted so far have taken accessibility into account. If your company sells software to public authorities in the USA, the European Union and a few other parts of the world, the software needs to conform to certain specific accessibility standards.

In the European Union, the relevant standard is EN 301 549, created as a result of a mandate from the European Commission and published by ETSI. For web-based interfaces, EN 301 549 refers to the success criteria for levels A and AA in the Web Content Accessibility Guidelines. For non-web software, the standard defines requirements that essentially transfer applicable WCAG requirements to software (and adds a few other ones).

The relevant requirement for timeouts in WCAG 2.1 is Success Criterion 2.2.1 Timing Adjustable, which reads as follows:

For each time limit that is set by the content, at least one of the following is true:

  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.

See also the associated document Understanding Success Criterion 2.2.1: Timing Adjustable. This document also links to several techniques you can use depending on the scenario that applies to your software.


Consider also what you do when there is a request to the server after a timeout. Do not just reject the request or redirect the page. Maybe an in-page popup to allow you to log in again, but consider carefully the user story if their session does timeout.

If you handle the timeout process neatly, you can reduce your timeout, which is a positive for security. If you expect users to be spending a lot of time reading or filling out pages then keep the timeout longer.

So consider your users, and consider your timeout story.


Supposing that timing out a web session is a solution to stop the unauthorized access to a computer and its data when the user is not present. Then the best solution is a system/local time-out; centralized in case of corporation.

IMO Web timeout should be just complementary to the previous security solution, so having only a short timeout period only when the page is accessed from non-corporation devices and the data is critical.

And if the web timeout has to be restrictive then detect the user event in current page as it was said in a post above; through mouse/keyboard/scroll events; AJAX,...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.