Give outbound HTTP requests a time budget
A checkout request waits on a supplier API. Without an intentional timeout budget, a slow dependency can occupy PHP workers long enough to make unrelated pages feel unavailable, particularly on a shared hosting account.
Bound connection and total time
$response = Http::connectTimeout(3)
->timeout(8)
->get($configuredSupplierUrl, ['sku' => $sku]);
This fragment assumes the URL comes from trusted configuration and the request's response is validated afterward. A timeout is not a successful empty response. Handle the connection exception as a failed dependency call and avoid overwriting existing data with defaults.
Retries consume the same user patience
Three attempts with an eight-second timeout can exceed the time budget of the original page request. Include retry delays and upstream work when deciding the total acceptable duration. Some work belongs in a background job with visible status instead of a synchronous customer request.
Retry only operations whose repetition is safe or protected by an idempotency contract. A timeout after a remote write does not prove the write failed. Blindly repeating a purchase or payment request can create duplicate effects.
Test a connection failure and a slow-response path through controlled fakes or a local test server. Verify the application presents a useful failure or pending state and does not claim completion. Observe real latency separately after deployment. The chosen numbers should be justified by the endpoint's role and provider behavior, not copied unchanged into every HTTP call.