System.CalloutException: Read timed out

HTTP callouts to external systems can take longer than expected. The Apex runtime gives up if a single callout doesn't return within the configured timeout (default 10 seconds, max 120 seconds).

Set the timeout explicitly

The default of 10 seconds is too short for almost any real API. Set it on every HttpRequest you build:

HttpRequest req = new HttpRequest();
req.setEndpoint(endpoint);
req.setMethod('POST');
req.setTimeout(120000);   // 120s — the platform maximum
req.setBody(payload);

HttpResponse res = new Http().send(req);

The unit is milliseconds. The maximum is 120,000 ms (120 seconds). After that the platform throws Read timed out regardless of your setting.

When 120 seconds isn't enough

Some external APIs genuinely take longer (legacy SOAP services, large file uploads, batch endpoints). Apex sync callouts cannot wait longer than 120s. Three options:

1. Async pattern. Have the remote API accept the request, return a job ID, and provide a separate GET /status/<id> endpoint. Your Apex polls the status endpoint; each poll fits inside 120s.
2. Continuation pattern. For Visualforce / Aura, use Continuation to free up the thread while the callout is in flight. The page returns to the user while the callout completes asynchronously.
3. Move to a queueable that retries. Catch the timeout, requeue with exponential backoff. The queueable runs in fresh async context; if your remote service is occasionally slow, the retry catches the next response.

Don't catch CalloutException blindly

A naive try/catch around the callout that swallows the exception silently is worse than the timeout itself — you proceed with empty data and corrupt downstream state. At minimum:

try {
    res = new Http().send(req);
} catch (CalloutException e) {
    // Log to Error_Log__c with payload + endpoint + timestamp.
    // Re-throw OR set a known failure state so the caller knows the call failed.
    throw new IntegrationException(
        'Callout to ' + endpoint + ' timed out after ' + req.getTimeout() + 'ms',
        e
    );
}

A diagnostic that often surprises people

The 120-second cap is per callout, but there's also a per-transaction total of 120 seconds across all callouts. Three slow APIs at 50 seconds each will fail the third even if no individual call exceeds the cap.

System.debug('Total callout time: ' + Limits.getCallouts() + ' callouts');

Plus the 100-callout-per-transaction cap. See Too many callouts: 101 for that one.

When the timeout is on the remote side

Sometimes "Read timed out" reflects the remote service timing out and dropping the connection mid-response. The Apex runtime then sees the connection close before all bytes arrived and reports it as a read timeout. If retrying with longer Apex timeouts doesn't help, the bottleneck is on their side — capture the request payload size, ask their team to raise their limit, and consider chunking the request.