🚨 Is Your Server Sick But Still Receiving Traffic? The Hidden Secret of Istio Outlier Detection

Aug 17, 2026

—

Hello! When operating services in an MSA (Microservice Architecture) environment, there are often dizzying moments. 😵 One of countless service instances suddenly starts failing to respond properly. However, the load balancer, unaware of this fact, continues to send user requests to the ailing instance… and ultimately, users are met only with 5xx error screens.

How can we prevent such situations? If you use Istio, there’s a very elegant solution. It’s the Outlier Detection feature! But do you know exactly how this feature works? If you thought it was a “feature that periodically pokes servers to check their status,” then you absolutely must read this article today! You’ll be able to correct a key misunderstanding and elevate your service stability to the next level.

🤔 Outlier Detection, What Exactly Are You?

Istio’s Outlier Detection is a feature that automatically identifies abnormally operating service instances (Pods) within the service mesh and temporarily removes them from load balancing targets.

It’s like a wise coach in a group running race who spots a runner falling behind or stumbling and lets them rest for a while. 🏃‍♂️💨 Thanks to this feature, a failure in a specific instance can be prevented from spreading to the entire service.

The key lies in the ‘method of detecting abnormal behavior’.

🕵️‍♂️ Passive Observer, Outlier Detection

To get straight to the point, Istio’s Outlier Detection is a passive health check method.

What does this mean? It’s easy to understand when compared to an active method.

Passive Method 🕵️‍♂️: It identifies problems by quietly observing the responses of actual traffic coming into the service. For example, if it detects consecutive 5xx errors from requests going to a specific instance, it determines, “Ah, this one is not doing well!” and temporarily removes it from the traffic pool. It does not send separate health check requests. It judges solely based on the results of ‘live traffic’.
Active Method 🩺: It sends health check requests, asking “Are you okay?” periodically, regardless of actual service traffic. Kubernetes’ Liveness/Readiness Probes are typical examples. It periodically sends requests to an endpoint like /healthz, and if a normal response (e.g., HTTP 200 OK) doesn’t arrive within a set time, it determines, “This one is sick!” and takes action.

Therefore, Istio’s Outlier Detection is indeed a passive method because it detects problems within the flow of actual traffic without sending separate requests.

⚙️ Exploring Outlier Detection Settings (YAML)

Explaining it in words alone might not give you a clear picture, right? Let’s check the code to see how Outlier Detection is configured in an actual Istio DestinationRule resource.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      # How many consecutive 5xx errors should occur before ejection
      consecutive5xxErrors: 3
      # Monitoring interval (scan status at this interval)
      interval: 10s
      # Minimum duration for which an instance is ejected once detected
      baseEjectionTime: 1m
      # Maximum percentage of instances that can be ejected from the load balancing pool
      maxEjectionPercent: 50

Let’s break down the outlierDetection settings in the YAML file above:

consecutive5xxErrors: 3: If a specific instance of the reviews service returns 5xx errors like 502, 503, or 504 3 times consecutively…
interval: 10s: Istio scans for such situations every 10 seconds…
baseEjectionTime: 1m: The detected problematic instance is excluded from traffic distribution targets for a minimum of 1 minute. (The actual exclusion time increases gradually, calculated as baseEjectionTime * number of ejections.)
maxEjectionPercent: 50: Even if many instances have problems, only up to 50% of the total instances are excluded to prevent the entire service from being paralyzed.

Nowhere in these settings can you find an active method configuration like “send a request to the /health path,” clearly showing that it operates solely based on the response results of actual traffic.

💡 So, Which One Is Better?

You might be thinking, “So, is the active method wrong, and should I only use the passive method?”

The answer is: “No, both are necessary and complementary!”


Category	Istio Outlier Detection (Passive)	Kubernetes Probes (Active)
Detection Method	Monitoring actual traffic responses 📊	Sending periodic health check requests (ping-pong)
Advantages	Immediately identifies issues affecting actual users. No overhead.	Can detect instance problems in advance even without traffic.
Disadvantages	Cannot detect problems if there is no traffic.	Health check requests themselves can add a slight load to the service.
Main Role	Protecting services from temporary overload or intermittent errors (traffic isolation)	Detecting when the application itself is down or unresponsive (container restart)

As you can see, the two methods solve different types of problems.

K8s Probe (Active): Detects fundamental problems such as a container being completely dead or a DB connection pool being full and unable to process further requests, and restarts the container.
Istio Outlier Detection (Passive): Detects instances that are alive but have temporarily unstable responses due to temporary CPU spikes or network delays, and temporarily isolates them from user traffic.

✨ Conclusion: Stronger Together!

In conclusion, Istio’s Outlier Detection is a passive health check method that monitors actual traffic. This is clearly distinct from active methods like Kubernetes’ Liveness/Readiness Probes, which send periodic health check requests.

The most ideal configuration is to use both together. 🤝

Preventing traffic from going to Pods that are not yet ready with Readiness Probe,
Restarting completely dead Pods with Liveness Probe, and
Maximizing service stability by temporarily isolating Pods that are momentarily “off” from the traffic pool with Outlier Detection.

Now, do you clearly understand how Istio’s Outlier Detection works and why it’s a ‘passive’ method? Accurately understand and apply this concept to build more robust and resilient microservices!