I recently had a discussion with a coworker about network timeouts. This person wanted to have 1 second timeouts because they believe the optimal user experience is one where the user doesn't have to wait long before knowing if something fails. However, at scale 1 second is far too short to cover the range of network conditions user may experience on a daily basis. The question becomes: what is a good timeout value, and how can you determine one from data rather than shooting in the dark?

Obviously you can perform an experiment with your user base, but I'm curious if there is history or literature or data supporting standard timeout lengths like 10 and 30 seconds. Or are these values simply conventional?


I'm not asking about user experience. I'm asking about networking. I want to know why, for example, the default socket timeout is 30 seconds.

  • Users aren't waiting to find out if something failed. Users patience times out independently. Just because your server beat the timeout doesn't mean the user hasn't already hit refresh or given up on you and started watching cat videos. Timeout messages don't help with that. They tell the user it's pointless to wait longer because their computer has given up timely to protect its resources. Commented Jul 4, 2017 at 5:45
  • If you anticipate something may take a while you can display a nice looking splash screen. With something that moves. Like a cat video. Or text like "This may take a while". It all depends on context, the type of user, the minimum and maximum delay you expect as a developer and what more. It is dealing with expectations, both yours and your user's. So no, there is no general number. Commented Jul 4, 2017 at 7:23
  • No cat videos. The most infurating user experience was "search" in an old Windows version where they showed an animation of a stupid fxxxing dog wagging its stupid fxxxing tail. I always wanted a real dog and a baseball bat when I saw that animation.
    – gnasher729
    Commented Jul 4, 2017 at 8:26
  • I think your co-worker is mixing up concepts - response time (that is what the user experiences) and timeout (this is what you build in in order to not let the application hang forever) are two entirely different things.
    – tofro
    Commented Jul 4, 2017 at 9:36
  • Timeouts vary from OS to OS, from connections to connotations (ADSL, optic fiber, 4g), from protocol to protocol (tcp, http, ...), from app to app.
    – Laiv
    Commented Jul 4, 2017 at 18:20

3 Answers 3


Your co-worker is totally wrong about the relationship between timeouts and user experience. Sure, the user would like a response within a second, but they want a successful response. Changing the timeout to a second doesn't help with that. I'd rather have an application that gives me what I want within three seconds than one that tells me within a second that I can't get what I want.

Your criterion should be: Set the timeout to a value x, so that it is very unlikely that the server will reply at all if it hasn't replied within x seconds. If you set it higher that doesn't help, if you set it lower you will miss out on valid responses from the server.

If you have server requests where you know that the user will be waiting: Send the request and start a timer. If the request doesn't respond within say a second, show a user interface that shows the app is busy and has a cancel button. If the request replies, remove that user interface (but leave it up for at least half a second to avoid "flashing" if a request takes exactly 1.1 seconds). If the user presses "Cancel", cancel the request if you can, make sure that any response that might arrive is ignored (when I cancel an operation, I expect it to be cancelled). You may display an error if you get a timeout after 60 seconds.

And if you have an operation that consists of multiple requests, treat it as one unit.

  • I mean.. I agree. But that's not what I'm asking about. Commented Jul 4, 2017 at 17:43

There have been articles regarding response times in order for us to have an acceptable delay from a psychological perspective.

Supposedly 0.1 seconds feels instantaneous for a user, after which the delay is noticeable.

1 second is the most amount of delay you can have where the user doesn't feel interrupted by the delay.

10 seconds is supposedly the maximum amount for a user's attention to be retained, after which users tend to want to do something else in the meantime.

Though I've never heard of 30 seconds used as any particular metric or "standard" waiting time, though I do see it used often.

Hope that helps!


I'd also like to refer to the NNGroup article @Neil posted. However, enforcing a timeout just for the sake of believing that it will heighten the user experience is beyond foolish.

Fast requests heighten the user experience, not timeouts generating error messages.

Saying something along the lines of "The request timed out, try again." is not likely at all to create any happy users. In fact it's likely going to create more infuriation since your job is to make sure that the request works properly. This is to say that the timeout has not increased the user experience in any conceivable way.

Now, let's move on to another area: What happens if the requests actually start slowing down due to something very simple such as increased load on the servers? Your users will be fine so long as a request takes less than one second.

What happens if they start taking more than one second? Well, all of a sudden you have a lot of users with requests which are timing out - And they are seeing error messages which are beyond their control to deal with. What happens when requests start timing out? From my personal experience people start refreshing/clicking buttons a lot. This is very likely to only heighten your load problems.

The question becomes: what's a good timeout value and how can you determine one from data rather than feeling like you're shooting in the dark?

This depends a lot on the request. Specifically, is it logical that a request may take a lot of time? Users are often willing to wait a while for things they expect to take time. Generating a report seems like a typical task where one might expect a delay of at least a few seconds but in these cases you can typically help the user anticipate some wait.

As a finishing point, I think setting 1 second as an ambition for the average request time to achieve is great but don't impose such an arbitrary rule upon your users.

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.