Static Thresholding

The core characteristic of static thresholding is the use of immutable, pre-defined values to trigger the circuit breaker's transition from a closed to an open state. Common thresholds include:

• Error Rate: e.g., trip if > 50% of requests fail.
• Request Volume: e.g., trip only after a minimum of 10 calls.
• Latency: e.g., trip if the 99th percentile response time exceeds 2000ms. These values are set during system configuration and do not change during runtime without a manual update or redeployment.

Because thresholds are static, the system's response to failure is predictable and repeatable. For a given load and error profile, the circuit breaker will always trip at the same point. This determinism is critical for:

• Debugging and Post-Mortems: Engineers can precisely reproduce failure scenarios.
• Capacity Planning: Teams can calculate the exact failure conditions a system can tolerate.
• Compliance Audits: Provides a clear, auditable rule for system behavior under stress.

Static thresholds are managed through configuration files, environment variables, or feature flags. This separates the operational logic from the application code, offering key advantages:

• Operational Agility: Thresholds can be adjusted (via config change) without code changes or redeploys.
• Environment-Specific Tuning: Different values can be set for development, staging, and production.
• Reduced Complexity: Eliminates the need for runtime algorithms to calculate dynamic thresholds, simplifying the system's state management.

Static thresholding is defined by what it is not: adaptive. Unlike adaptive circuit breakers that use machine learning or real-time traffic analysis to adjust thresholds, static systems lack this feedback loop.

• Pros: Simpler, more stable, no risk of threshold oscillation.
• Cons: Less responsive to changing baseline performance or seasonal traffic patterns. May be too sensitive during brief spikes or too permissive during gradual degradation.

The primary engineering goal is to prevent cascading failures. A statically configured breaker acts as a pressure relief valve for a specific downstream service (e.g., a payment API, database).

• Implementation: A service mesh sidecar or client library monitors calls to the dependency.
• Action: When the static error threshold is breached, the breaker opens. All subsequent calls fail fast (often returning a predefined fallback) for a configured duration, allowing the failing dependency time to recover without being overwhelmed by retries.

Static thresholds create clear, monitorable events. When a breaker trips, it generates high-signal telemetry for observability platforms.

• Metrics: A gauge for the breaker state (0=closed, 1=open) and a counter for trip events.
• Alerts: Can be configured to fire when the breaker opens, providing immediate notification of a protected service failure.
• Dashboards: The fixed thresholds provide clear reference lines (e.g., a line at 50% error rate) against which to visualize real-time performance.

The most fundamental static threshold. The circuit breaker trips when the percentage of failed requests exceeds a pre-defined limit over a rolling window. This directly prevents cascading failures from a degraded dependency.

• Typical Configuration: failureRateThreshold = 50.0 (50%)
• Rolling Window: Often set to 60 or 100 requests (rollingWindow.size = 100).
• Calculation: Failures / Total Calls within the window.
• Use Case: A downstream API begins returning 5xx errors. Once the error rate crosses 50% within the last 100 calls, the breaker opens, failing fast for all new requests.

Trips the breaker based on the proportion of calls that exceed a static latency threshold. This protects the calling system from a dependency that is unresponsive or severely degraded, even if it's not returning errors.

• Typical Configuration: slowCallRateThreshold = 100.0 (100%) with slowCallDurationThreshold = 10000ms (10 seconds).
• Mechanism: Any call taking longer than the slowCallDurationThreshold is counted as 'slow'. If 100% of calls are slow, the breaker opens.
• Use Case: A database query becomes deadlocked. Calls don't fail immediately but hang. This configuration would trip the breaker after all calls in the window exceed 10 seconds, freeing application threads.

A minimum traffic requirement for the circuit breaker to evaluate its other thresholds. This prevents the breaker from tripping under low-traffic conditions where a small number of failures could create a misleading statistical picture.

• Typical Configuration: minimumNumberOfCalls = 10
• Function: The error rate or slow call rate is only calculated once the number of calls within the rolling window meets this minimum.
• Use Case: During system startup or low-usage periods, a single failed call could represent a 100% error rate. This threshold ensures a statistically significant sample size before tripping.

A static limit on the number of test requests allowed when the circuit breaker is in the half-open state. This state occurs after a wait duration, allowing the system to probe if the dependency has recovered.

• Typical Configuration: permittedNumberOfCallsInHalfOpenState = 3
• Workflow: After the breaker has been open for a configured time, it moves to half-open. It allows a limited number (e.g., 3) of calls through. If these succeed, the breaker closes. If any fail, it re-opens.
• Use Case: Prevents a flood of traffic from overwhelming a service that is just coming back online, allowing it to stabilize.

A fixed timer that determines how long the circuit breaker remains in the open state before transitioning to half-open. This gives the failing dependency time to recover.

• Typical Configuration: waitDurationInOpenState = 60000ms (1 minute).
• Behavior: All requests are failed immediately during this period. After the timer elapses, the state changes to half-open for a probe.
• Use Case: A crashed service may need 30-60 seconds to restart. This static duration prevents the caller from incessantly attempting requests during the recovery period.

Static thresholds are simple, predictable, and easy to reason about, but lack context. Adaptive thresholds dynamically adjust based on real-time traffic patterns and historical baselines.

Key Differences:

• Static: errorThreshold = 50% (always).
• Adaptive: errorThreshold = mean(trafficBaseline) + 3*stddev (changes).
• Trade-off: Static configurations can be too sensitive during traffic spikes or too lenient during sustained degradation. Adaptive breakers require more complex telemetry but can respond to the system's actual behavior.

A circuit breaker that dynamically adjusts its trip thresholds based on real-time analysis of system performance and traffic patterns, rather than using fixed, pre-configured values. This approach uses machine learning or statistical models to set optimal thresholds for metrics like error rate or latency, allowing the system to respond to changing conditions such as diurnal traffic patterns or gradual performance degradation of a downstream service.

A circuit breaker configuration strategy where the breaker opens based on the violation of a Service Level Objective (SLO), such as a target error budget or latency percentile. Instead of a simple static error rate (e.g., 50%), it uses a business or reliability metric. For example, a breaker might trip if the 99th percentile latency exceeds 500ms for two consecutive minutes, directly protecting user-experience guarantees.

A core metric, usually calculated over a rolling time window, that represents the proportion of requests that result in errors. It is the primary signal used by static thresholding to make a trip decision.

• Calculation: (Failed Requests / Total Requests) * 100% over the window.
• Example: A static threshold might be configured to open the circuit if the failure rate exceeds 50% for a 60-second window. This provides a simple, understandable trigger condition.

A time-based sliding window used to calculate metrics like failure rate or latency for circuit breaker decisions. Only the most recent data within the window is considered, providing a current view of system health and preventing stale data from affecting the breaker state.

• Purpose: Ensures the circuit breaker reacts to recent failures, not historical ones.
• Static Configuration: The window duration (e.g., 10 seconds, 1 minute) is often a fixed parameter set alongside the error threshold.

A periodic diagnostic request sent to a service or component to verify its operational status and readiness to handle traffic. In circuit breaker patterns, health checks are often used during the half-open state to test if a previously failing dependency has recovered.

• Active vs. Passive: Can be explicit probes (active) or inferred from application traffic (passive).
• Integration: Static thresholding typically relies on passive health checks derived from real request outcomes.

A Site Reliability Engineering (SRE) concept defining the maximum allowable amount of unreliability (errors, downtime) a service can have over a period without violating its SLO. While static thresholding uses a simple error rate, an error budget provides a more nuanced, time-bound allowance for failure.

• Connection: A circuit breaker can be seen as an enforcement mechanism for an error budget, stopping traffic when the budget is being consumed too quickly to prevent a full SLO violation.