instruction: How do you deploy and configure Linkerd service mesh?
output: Configuring Timeouts | Linkerd Docs Community Get Involved Adopters & Case Studies Linkerd Ambassadors Become an Ambassador Buoyant's Linkerd Forum Blog FAQ Enterprise Star Join Forum Announcing Linkerd 2.18: Battlescars, lessons learned, and preliminary Windows support Learn more You are viewing docs for an older version of Linkerd. View the latest docs . Linkerd edge Linkerd 2.18 Linkerd 2.17 Linkerd 2.16 Linkerd 2.15 Linkerd 2.14 Linkerd 2.13 Linkerd 2.12 Linkerd 2.11 Linkerd 2.10 Overview Getting Started Features HTTP, HTTP/2, and gRPC Proxying TCP Proxying and Protocol Detection Retries and Timeouts Automatic mTLS Ingress Telemetry and Monitoring Load Balancing Authorization Policy Automatic Proxy Injection CNI Plugin Dashboard and on-cluster metrics stack Distributed Tracing Fault Injection High Availability HTTP Access Logging Multi-cluster communication Proxy Init Iptables Modes Service Profiles Topology Aware Routing Traffic Split (canaries, blue/green deploys) Tasks Adding your services to Linkerd Automated Canary Releases Automatic Multicluster Failover Automatically Rotating Control Plane TLS Credentials Automatically Rotating Webhook TLS Credentials Bringing your own Prometheus Configuring Per-Route Policy Configuring Proxy Concurrency Configuring Retries Configuring Timeouts Control Plane Debug Endpoints Customizing Linkerd's Configuration with Kustomize Debugging 502s Debugging gRPC applications with request tracing Debugging HTTP applications with per-route metrics Distributed tracing with Linkerd Enabling Topology Aware Routing Exporting Metrics Exposing the Dashboard Generating your own mTLS root certificates Getting Per-Route Metrics Getting started with Linkerd SMI extension Graceful Pod Shutdown Grafana Ingress traffic Injecting Faults Installing Linkerd Installing Linkerd with Helm Installing Multi-cluster Components Linkerd and Pod Security Policies (PSP) Manually Rotating Control Plane TLS Credentials Modifying the Proxy Log Level Multi-cluster communication Multi-cluster communication with StatefulSets Replacing expired certificates Restricting Access To Services Rotating webhooks certificates Securing Linkerd Tap Setting Up Service Profiles Troubleshooting Uninstalling Linkerd Uninstalling Multicluster Upgrading Linkerd Using a Custom Cluster Domain Using A Private Docker Repository Using extensions Using GitOps with Linkerd with Argo CD Using the Debug Sidecar Validating your mTLS traffic Reference Architecture Authorization Policy CLI authz check completion diagnostics identity inject install install-cni jaeger multicluster profile uninject uninstall upgrade version viz Cluster Configuration Extensions List Helm Chart Version Matrix IPTables Reference Proxy Configuration Proxy Log Level Proxy Metrics Service Profiles What is a service mesh? Frequently Asked Questions Releases and Versions Design Principles Going to Production Service Mesh Glossary Configuring Timeouts To limit how long Linkerd will wait before failing an outgoing request to another service, you can configure timeouts. These work by adding a little bit of extra information to the service profile for the service you&rsquo;re sending requests to. Note Routes configured in service profiles are different from HTTPRoute resources. Service profile routes allow you to collect per-route metrics and configure client-side behavior such as retries and timeouts. HTTPRoute resources, on the other hand, can be the target of AuthorizationPolicies and allow you to specify per-route authorization. Each route may define a timeout which specifies the maximum amount of time to wait for a response (including retries) to complete after the request is sent. If this timeout is reached, Linkerd will cancel the request, and return a 504 response. If unspecified, the default timeout is 10 seconds. spec : routes : - condition : method : HEAD pathRegex : /authors/[^/]*\.json name : HEAD /authors/{id}.json timeout : 300ms Check out the timeouts section of the books demo for a tutorial of how to configure timeouts. Monitoring Timeouts Requests which reach the timeout will be canceled, return a 504 Gateway Timeout response, and count as a failure for the purposes of effective success rate . Since the request was canceled before any actual response was received, a timeout will not count towards the actual request volume at all. This means that effective request rate can be higher than actual request rate when timeouts are configured. Furthermore, if a response is received just as the timeout is exceeded, it is possible for the request to be counted as an actual success but an effective failure. This can result in effective success rate being lower than actual success rate. Linkerd was originally created by Buoyant View Code of Conduct Community GitHub Slack Linkerd Forum Follow Linkedin YouTube Twitter Edit This Site Copyright © 2025 Linkerd Authors. All rights reserved.