A request can stall while connecting, waiting for headers, or reading a response. A timeout that covers only one of those phases may still leave the listener watching a spinner for too long.
Choose a total budget for the user action first. A search suggestion and a background catalog refresh do not need the same deadline.
Budget the whole path
Your browser calls your server, and your server calls the provider. If each layer waits for the full user budget, the total experience can exceed what you intended. Give the upstream call enough time to finish while leaving room for your server to return a useful response.
Cancel work when the original action is no longer needed. A listener who closes a search menu should not cause an unlimited background request to continue merely because its timeout has not expired.
Be careful with retries. Three five-second attempts are not a five-second action. Track time remaining and stop when another attempt cannot fit. Keep optional loading separate from a critical request so one delayed image does not consume the search budget.
Test each slow phase
Use a controlled test server that delays connection handling, response headers, and body delivery separately. Confirm that your client stops within the expected total time and cleans up its loading state.
Retain already available results when possible. An error message should let the listener retry without retyping the query. Do not say “no podcasts found” when the request simply ran out of time.
Measure real durations after release. The purpose of a timeout is a predictable limit, not proof that every response will be fast. Keep the chosen budgets and the reason for them in the integration's operational notes.