What is the length of time the average user will wait at a wait indicator (i.e. a spinning circle, beach-ball-of-death, egg-timer) before they think something has gone wrong?

If anybody can point to any research to back up answers that would be a bonus.

I am mainly thinking in context of websites or within desktop applications rather than waiting for an action the user knows could take a long time i.e. waiting for a application to install or for Windows to boot to desktop.

  • 9
    That's really going to depend on the situation where they encounter the indicator. (i.e. if they're waiting for a complex PC game to load it's likely they'll be more patient than if they're trying to select a navigation link on a simple website). What situation do you have that made you ask this question?
    – JonW
    Commented Feb 14, 2013 at 9:43
  • 1
    That will also depend upon how attractive/interesting/reliable/visible/clear that waiting indicator is! ;)
    – Mohit
    Commented Feb 14, 2013 at 9:46
  • 3
    Not directly applicable, but there was an interesting question relating to slow application start-up times a while ago: ux.stackexchange.com/questions/29181/…
    – CJF
    Commented Feb 14, 2013 at 9:57
  • 1
    @CJFranken Amazing.
    – dav_i
    Commented Feb 14, 2013 at 10:04
  • I found a more recent blog entry from Jakob Nielsen, where he refers to his study from 1993, stating that the values are still valid. I edited my answer to include the newer article quote. The explanations are also more detailed now.
    – J_rgen
    Commented Feb 21, 2013 at 13:11

7 Answers 7


If we ask UX-guru Jakob Nielsen it's 10 seconds. Longer waiting times could get the user to leave the program/page and do other stuff in the meantime. Supposing that something has gone wrong also depends on the users anticipation on how long a certain task could possibly take and the kind of task itself.

Original (1993): http://www.nngroup.com/articles/response-times-3-important-limits/

Revised Version (2010), taken from http://www.nngroup.com/articles/website-response-times/

The 3 response-time limits are the same today as when I wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

  • 0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation (direct manipulation is one of the key GUI techniques to increase user engagement and control — for more about it, see our Human Computer Interaction (HCI) for Real World Problems seminar).
  • 1 second keeps the user's flow of thought seamless . Users can sense a delay, and thus know the computer is generating the
    outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This
    degree of responsiveness is needed for good navigation . 10 seconds
    keeps the user's attention . From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can
    handle it.
  • After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer
    finally does respond. A 10-second delay will often make users leave a site immediately. And even if they stay, it's harder for them to understand what's going on, making it less likely that they'll succeed in any difficult tasks.

Even a few seconds' delay is enough to create an unpleasant user experience. Users are no longer in control, and they're consciously annoyed by having to wait for the computer. Thus, with repeated short delays, users will give up unless they're extremely committed to completing the task.

  • 5
    Very good suggestion, but I would like to add that those limits were measured back in 1993, 20 years ago. I can imagine that user's patience has changed quite a bit in these fast-moving times.
    – user12741
    Commented Feb 14, 2013 at 12:02
  • 1
    I would question the data behind Nielsen's results. That seems to be simply an observation of the order of magnitude rather than any hard data.
    – JohnGB
    Commented Feb 14, 2013 at 12:23
  • 2
    UX is all about observation. "Hard data" isn't that significant because auf the diversity of users and domains - that's why individual testing is so important.
    – J_rgen
    Commented Feb 14, 2013 at 13:28
  • The studies these limits are based on are in fact already 40 years old. However, Nielsen states that the values are still applicable to todays user needs. So we can assume we are dealing with very fundamental human behavior here. I edited the answer and included a revised version of Nielsen's article.
    – J_rgen
    Commented Feb 21, 2013 at 13:25
  • These studies by Nielsen seem to have addressed only the speed at which a site is rendered the speed or at which the site appears to respond to user input. It does not seem to include an evaluation of sites with an explicit wait dialog. As such, although Nielsen's cited findings are informative, I don't think they are directly applicable to this question.
    – Mike Rice
    Commented Feb 25, 2013 at 18:43

If you expect it to take a lot of time, instead of just a spinning circle you could add progress indicator. Progress indicators are almost perfect from the users perspective, they have just one weak side - they should reflect the TIME spent on waiting, and not DATA PROCESSED, but from programming point of view there are too many dependencies to say that a process will take, say, 10 seconds in general. As an effect, user can either see progress going from 0 to 40% in the first 3 seconds, and from 40 to 70% takes 30 seconds. Or even worse: user is presented a progress indicator going from 0 to 100% and then he can still see a spinning circle for god only knows how long. At 100% he or she will really feel something is wrong.

A good progress indicator, methinks, in situations where you cannot tell how long (measured in time) the process wil take, should be switched from 0-100% to some relative data. Just to inform user that something works in the background (just in this case). User will not know how much more time it will take, but at least he or she will know that the background process works.

So, there are two things you should do: a good wait indicator + a good progress indicator.

Here is a simple visualization:

enter image description here

  • 10
    xkcd.com/612 Commented Feb 14, 2013 at 13:35
  • 5
    @DanNeely I'm reckoning that in a couple of years for every situation in life there'll be an appropriate xkcd
    – icc97
    Commented Feb 14, 2013 at 14:02

I lot depends on what the person is waiting for.

I can't recall where I read it, but for airline flight bookings it was found that a short wait had a worse response than a longer one. If it were longer (and showed some fake activity), the customers had a better confidence in the algorithm and results. The same applies for insurance quotes and similar actions that have a perception of being more complex.

The overall rule is to make customer facing actions as fast as possible. If it has to be slower, you should show some progress bar (with tricks to make is seem faster) or information (even if it's dummy info) to communicate that something important is happening.

  • 3
    This question has some info on this, such as how the Coinstar machines added an intentional delay into their operation to give customers a better expereince of the machine: ux.stackexchange.com/questions/29285/…
    – JonW
    Commented Feb 14, 2013 at 12:38
  • Very interesting,so if people are waiting for cheaper results or money saving results they are willing to wait?
    – Mervin
    Commented Feb 14, 2013 at 16:04
  • 2
    @Mervin Not necessarily. If people are waiting for a result that the perceive to be complexed to obtain, and they want a better result, they are willing to wait. In fact, they expect to wait.
    – JohnGB
    Commented Feb 14, 2013 at 16:17
  • makes sense :) but my comment was also tongue in cheek since if the system responded quickly with flight fares, you would wonder if it really did search across all flights and if there was a cheaper flight available
    – Mervin
    Commented Feb 14, 2013 at 16:19

Wait time is closely related to perceived performance. Steve Seow has an excellent book titled Designing and Engineering Time: The Psychology of Time Perception in Software.

One of its major results is how we perceive response time:

  • "instantaneous" (0.1 – 0.2 seconds)
  • "immediate" (0.5 – 1 second)
  • "longer" (2-5 seconds or more)

How long they're willing to wait depends on several factors, including what they think is the complexity of the task. There's a relationship between how complex users perceive the task is and how long they will wait for it before getting concerned that something has gone wrong.

One of the best methods to address a user's concern over the time it takes to complete a task is to use determinate progress indicators whenever possible. That way, users have an indication of how much has been done and how much is remaining. Being able to see that there is progress being made, instead of just an indeterminate progress indicator (which, as I'm sure we've all experienced, can just indicate that the task will never complete), gives the user much more confidence in the system and helps build trust.


I once waited over 24 hours for a Java applet to load. After the first few seconds, I started multitasking. After about 10 seconds, I reloaded the page. 10 seconds later, I threw the browser to a distant desktop and carried on with my day, feeling quite disappointed with the Java applets in general. But maybe the applet or it's server was doing a lot of work, I thought; it was supposed to visualize a lot of data. The next day, I was cleaning up a bunch of windows that I had scattered across six desktops, and I noticed that the Java logo was still spinning!

My point is that you should put an upper limit on how long you will ask a user to wait without meaningful feedback, because some of them will wait long enough to get a very bad impression. I don't even bother installing Java in the browser any more.


A user willing to get something from a web site will allot the site a number of patience units, a quota.
The number of units depends on the site's expected outcome, or the interest of the user in that outcome.
In some cases the quota might be infinite, like for example when the user is doing taxes through a web interface, by force.
As the site provides value, the user might allot more units. On the other hand, if the site lags behind the user's expectations then it (the site) starts consuming patience units.
When the remaining number of units reaches zero the user leaves.

All the progress indicators and hypnotic revolving animations are attempts to make the user refrain from withdrawing patience units from the current session.

So, there is not a fixed time after which the user will leave.
To make your users stay offer them great value. Or faster response times.

There is another facet, like building confidence through honesty. @Dominik's visualization is a good example, in that it sincerely communicates the user for how long will he have to wait, as opposed to the phony stay in line messages from some call centers.

If the users know the value of what they are waiting for, and more or less how long the wait will take, then they can make an informed decision no matter what Nielsen sais.
Web sites should not attempt to influence them; maybe begging would be right: please don't go!.


It's not so much about expected wait times but, more about setting reasonable expectations and always meeting or exceeding them. It's quite a challenge to first of all set correct targets and then ALWAYS deliver on time or gracefully back out when operations don't go as planned. Users are as patient as you want them to be, within reasonable limits. Three minutes for a typical browser blocking wait to fail retrieving data is not a good user experience and they'll close the window before then. Start with non-blocking ajax to retrieve resources or commit data, use good logic in SQL etc to do things efficiently and most importantly lots of defensive programming. Most half-baked kocky programmers are over-confident in their code, assuming it's so good that it hardly needs much error handling. Make sure you don't unknowingly lose your users before you even start setting time/performance expectations.

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.