HTTP 408 Request Timeout vs gRPC 4 DEADLINE_EXCEEDED
HTTP 408 and gRPC DEADLINE_EXCEEDED both indicate that a request took too long, but the timeout is controlled differently. HTTP 408 means the server gave up waiting for the client to finish sending the request, while gRPC DEADLINE_EXCEEDED means the client-set deadline expired before the server could respond.
Description
The server timed out waiting for the request. The client did not produce a request within the time the server was prepared to wait.
When You See It
When a client takes too long to send the complete request (slow upload, network issues).
How to Fix
Retry the request. Check your network connection. Reduce request payload size.
Description
The deadline expired before the operation could complete. For operations that change the state of the system, this error may be returned even if the operation has completed successfully.
When You See It
The RPC took longer than the configured deadline allows. Common in slow network conditions, overloaded servers, or when the deadline is set too aggressively.
How to Fix
Increase the client deadline, optimize the server-side processing, or add server-side caching. If the operation might have succeeded, check idempotency before retrying.
Key Differences
HTTP 408 is server-initiated — the server timed out waiting for the client to complete the request.
gRPC DEADLINE_EXCEEDED is client-initiated — the client set a deadline and the server could not respond in time.
gRPC deadlines propagate across service boundaries, creating a distributed timeout chain; HTTP 408 is single-hop.
gRPC DEADLINE_EXCEEDED may mean the operation actually completed but the response arrived too late.
HTTP 408 is rare in practice; gRPC DEADLINE_EXCEEDED is very common in microservice architectures.
When to Use Which
HTTP 408 is returned when a client opens a connection but does not send the full request in time — rarely used in practice. gRPC DEADLINE_EXCEEDED is returned when the client-specified deadline expires. Set gRPC deadlines based on expected latency and ensure idempotent operations when retrying, since the server may have already completed the work.