API服务器标准可接受请求/响应超时时间是多少？为何存在800ms、1200ms这类常见默认超时值？

Great question—this is something a lot of devs grapple with when tuning APIs and client-side code, since timeout values directly impact both user experience and system stability. Let’s break this down clearly:

First off, there’s no one-size-fits-all "standard" timeout, but the industry consensus leans toward 1–5 seconds for user-facing APIs. Here’s why that range makes sense:

• User perception: Research shows that users start noticing delays after ~1 second, and abandon interactions entirely if they wait more than 5 seconds. Keeping timeouts within this window ensures your app feels responsive, even when under load.
• System reliability: Timeouts prevent resource leaks on both the client and server side. If a client hangs waiting for a response indefinitely, it can tie up connections and memory; on the server, unresponsive requests can clog worker threads. A 1–5s window balances giving the server enough time to process valid requests while cutting off stuck ones.
• Distributed system guardrails: In microservices architectures, long timeouts can cause cascading failures—if one service times out slowly, it can back up requests across your entire stack. Shorter timeouts (1–3s for critical paths) limit the blast radius of a single slow service.

For internal APIs (not user-facing), you can safely use longer timeouts (5–10 seconds) since they’re not directly tied to user experience, and internal networks are typically more stable.

Those specific numbers aren’t arbitrary—they’re rooted in practical performance goals and historical context:

• Near-instant user experience: The 800ms mark sits just below the 1-second threshold where users start perceiving delay. Frameworks often set this as a default to prioritize snappiness, assuming most simple requests (like fetching user data) can complete well within that window, with a small buffer for network jitter.
• Balanced buffer for variability: 1200ms is a common default for slightly more complex requests, or apps targeting users in regions with less reliable internet. It adds a 20% buffer to the 1-second "perceptually instant" mark, accounting for network round-trip delays (RTT) or minor server load spikes without pushing into the "slow" zone for users.
• Historical framework conventions: Many early HTTP client libraries (think old Java HTTP clients, or early frontend fetch wrappers) adopted these values as defaults back when server hardware and network speeds were slower. Over time, they became de facto standards that newer tools inherited.
• SLO alignment: Teams often set timeouts to match their Service Level Objectives (SLOs). For example, if your SLO is "95% of requests complete in 1 second," an 800ms timeout ensures that only the slowest 5% of requests get terminated, keeping your error rates aligned with your reliability goals. A 1200ms timeout might be used if you want to be more lenient, giving borderline requests a chance to finish.

Remember, these defaults are just starting points. You should always adjust timeouts based on your specific use case:

• For CPU-intensive API calls (like image processing), you’ll need longer timeouts (3–5s).
• For real-time features (like chat), keep timeouts short (500–1000ms) and implement retries with backoff.
• For asynchronous tasks, avoid tight timeouts entirely—use webhooks or polling instead.

内容的提问来源于stack exchange，提问作者Saber Alex