Feb 21, 2024: Announcing Linkerd 2.15 with support for VM workloads, native sidecars, and SPIFFE! Read more »

This is not the latest version of Linkerd!
This documentation is for Linkerd 1.x, an older version with some significant differences. You may want to see the Linkerd 2.x (current) documentation instead.

Retries and deadlines

Failures are inevitable in a distributed system. Linkerd comes with several configurable options that help make clients and servers more fault-tolerant and reliable.


Linkerd can automatically retry requests on certain failures (for example, connection errors). See the configuration documentation for examples. Linkerd comes with a few HTTP response classifiers that determine which HTTP responses should be considered failures and which can be retried. Thus, even if one instance of a service is failing, clients can maximize success rates. Retry budgets (the percentage of requests that Linkerd will retry) are configurable so that you can avoid overloading your server.


You can also specify a per-request timeout on the router level so that the service does not spend an inordinate amount of time on a request. This, coupled with deadlines, allows you to use your services more efficiently.


Deadlines allow you to specify time bounds within which a request is expected to be satisfied (or within which the response is still useful). This is very handy to avoid occupying your service’s resources trying to fulfill very long-running requests. This feature is not fully implemented yet, but is coming soon.

For more info on deadlines related to service to service communication, check out Marius Eriksen’s article.