Introduction

On Android, an HTTP “response timeout” is usually the read timeout, which controls how long the client waits for data after the connection has been established. In practice, you should think about three separate limits: connect timeout, read timeout, and sometimes an overall call timeout.

Using HttpURLConnection

If you are using HttpURLConnection, the two main timeout settings are setConnectTimeout and setReadTimeout.

1import java.io.BufferedInputStream;
2import java.io.IOException;
3import java.io.InputStream;
4import java.net.HttpURLConnection;
5import java.net.URL;
6
7public class NetworkUtil {
8
9    public static String getDataFromServer(String urlAddress) throws IOException {
10        URL url = new URL(urlAddress);
11        HttpURLConnection connection = (HttpURLConnection) url.openConnection();
12
13        try {
14            connection.setConnectTimeout(10_000);
15            connection.setReadTimeout(15_000);
16
17            InputStream in = new BufferedInputStream(connection.getInputStream());
18            return new String(in.readAllBytes());
19        } finally {
20            connection.disconnect();
21        }
22    }
23}

Here:

• connect timeout is 10 seconds
• read timeout is 15 seconds

That means the app will not wait forever either to establish the connection or to receive the response body.

Using OkHttp

If your project uses OkHttp, timeout configuration is usually cleaner and more expressive.

1import java.io.IOException;
2import java.util.concurrent.TimeUnit;
3import okhttp3.OkHttpClient;
4import okhttp3.Request;
5import okhttp3.Response;
6
7public class HttpUtil {
8
9    private static final OkHttpClient client = new OkHttpClient.Builder()
10            .connectTimeout(10, TimeUnit.SECONDS)
11            .readTimeout(15, TimeUnit.SECONDS)
12            .writeTimeout(15, TimeUnit.SECONDS)
13            .callTimeout(20, TimeUnit.SECONDS)
14            .build();
15
16    public static String getWebContent(String url) throws IOException {
17        Request request = new Request.Builder()
18                .url(url)
19                .build();
20
21        try (Response response = client.newCall(request).execute()) {
22            if (response.body() == null) {
23                return "";
24            }
25            return response.body().string();
26        }
27    }
28}

The extra callTimeout is useful because it limits the total time for the entire request, not just one stage of it.

Which Timeout Is the “Response Timeout”

People often say “response timeout” when they really mean “read timeout.” That is usually correct in casual conversation, but it helps to be precise:

• connect timeout: time allowed to open the connection
• read timeout: time allowed while waiting for data to be read
• write timeout: time allowed while sending request data
• call timeout: total request lifetime

If your app connects successfully but then hangs waiting for bytes, the read timeout is the relevant setting.

Choose Reasonable Values

There is no universal perfect number, but a common practical range is:

• connect timeout around 5 to 15 seconds
• read timeout around 10 to 30 seconds

The right numbers depend on:

• backend latency expectations
• payload size
• mobile network quality
• whether the request is interactive or background work

An image upload on weak mobile data may need a different timeout policy than a tiny JSON lookup for a search suggestion.

Handle Timeout Exceptions Properly

Setting a timeout is only half the job. You also need to handle the failure path gracefully.

1try {
2    String content = HttpUtil.getWebContent("https://example.com");
3    System.out.println(content);
4} catch (IOException e) {
5    System.out.println("Network request failed or timed out: " + e.getMessage());
6}

On Android, that usually means:

• show a retry option
• display a user-friendly message
• avoid blocking the UI forever

Time limits are useful only if the user experience also responds sensibly when they are reached.

Do Not Run Network Calls on the Main Thread

Even perfectly configured timeouts do not make blocking network code safe on the UI thread.

Use:

• background threads
• coroutines
• executors
• or a networking layer such as Retrofit on top of OkHttp

The timeout protects the request. It does not justify doing network I/O on the main thread.

Common Pitfalls

The most common pitfall is setting only the connect timeout and forgetting the read timeout. The app then connects successfully but may still hang waiting for data.

Another mistake is using extremely large timeout values to “fix” network issues. That usually just delays failure and makes the user wait longer.

A third issue is assuming every request should use the same timeout policy. Interactive requests and large uploads often need different settings.

Finally, some developers configure timeouts but do not handle the resulting exceptions in a user-friendly way.

Summary

• On Android, the “response timeout” is usually the read timeout.
• 'HttpURLConnection uses setConnectTimeout and setReadTimeout.'
• OkHttp also supports write and total call timeouts.
• Choose timeout values based on real network and product expectations, not guesswork alone.
• Always handle timeout failures cleanly and keep network work off the main thread.