Both. A deadline is a point in time after which a client will not wait for an answer. By default gRPC sets none, so a slow or stuck call can hold resources indefinitely. Setting realistic deadlines on clients and defensive timeouts on servers limits how long any one request can tie up your service.
What the gRPC documentation says
The gRPC deadlines guide states that by default gRPC does not set a deadline, which means a client can end up waiting effectively forever, and that you should always set a realistic deadline explicitly. If the server goes past the deadline, the client gives up with a DEADLINE_EXCEEDED status.
On the server, a call is cancelled automatically once the client's deadline passes. The guide stresses that the server application is responsible for stopping any activity it started for the call. A long running process should periodically check whether the call was cancelled, and stop.
The guide also describes a risk from the other direction. A server may receive calls with an unrealistically short deadline that it cannot meet, wasting resources, and in the worst case crashing.
Why this matters for security
Resource exhaustion is a classic way to take a service down. OWASP's API Security Top 10 lists missing or poorly set execution timeouts among the limits whose absence makes an API vulnerable to unrestricted resource consumption. OWASP's gRPC cheat sheet recommends configuring both client side and server side timeouts, and shows a server that applies a defensive timeout when the client has not set a short enough one.
Without a deadline, an attacker, or a buggy client, can open many calls that never finish. Each holds memory, a connection and maybe a database handle.
Client side and server side
| Side | What to do | Why |
|---|---|---|
| Client | Always set an explicit deadline | Avoid waiting forever |
| Server | Apply a maximum timeout regardless | Do not trust the client's value |
| Server | Check for cancellation in long work | Stop wasted effort |
| Chain of services | Propagate the incoming deadline | Downstream work stops too |
Deadline propagation is covered in the gRPC guide. Some implementations propagate automatically, while in others you must enable it. The guide notes that gRPC converts the deadline to a remaining timeout, so clock differences between servers do not break it.
Steps
- Search client code for calls made without a deadline. Add one per method, based on measured latency plus margin.
- In each server handler, wrap work in a context with a maximum timeout, so a missing or long client deadline cannot extend it.
- In long running handlers, check cancellation inside loops and before expensive steps.
- Enable deadline propagation for services that call other services.
- Decide a floor as well. Reject calls whose deadlines are too short to succeed, to avoid wasted work.
- Alert on rising DEADLINE_EXCEEDED counts. A spike can signal an attack or a failing dependency.
- Pair with message and stream limits.
A common mistake
Teams set a timeout on the HTTP gateway and assume the backend stops. It may not: the backend keeps working after the gateway gives up unless cancellation is propagated and honoured. Test it by calling a slow method, cancelling from the client, and watching the server.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how monitoring surfaces changes over time, and think about which timeout metrics you would alert on.
Quick check
Does gRPC set a default deadline?
No. The gRPC documentation says no deadline is set by default, so clients should set one explicitly.
Does the server stop work automatically after a deadline?
The call is cancelled, but your code must check for cancellation and stop activity it started.
Safeguard scans your dependencies and SBOMs for known vulnerabilities, including gRPC libraries, and shows which are reachable. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
