Presets
Presets provide ready-made circuit breaker configurations so you don't have to tune individual settings. Pick the one that best matches your backend's reliability profile.
Production presets
These presets are safe to use in all environments, including production.
BALANCED (default)
The default for every integration. Works well when your backend is reasonably reliable and you don't need special tuning.
When to use: Most integrations. Start here and only switch if you observe specific issues.
| Setting | Value |
|---|---|
| Error threshold | 50% |
| Timeout | 20s |
| Reset timeout | 15s |
| Min. calls before tripping | 20 |
AGGRESSIVE
Trips quickly at the first sign of trouble. Protects the storefront from slow backends by failing fast and shedding load early.
When to use: Fast, reliable backends where any slowdown is abnormal and should be caught immediately. Good for high-traffic storefronts where queued requests could cascade.
| Setting | Value |
|---|---|
| Error threshold | 30% |
| Timeout | 5s |
| Reset timeout | 10s |
| Min. calls before tripping | 10 |
FAST_FAILURE
Ultra-fast detection with a very short reset window. The breaker trips quickly and recovers quickly, minimizing downtime for brief backend hiccups.
When to use: Latency-sensitive flows like checkout or payment where a slow response is worse than an immediate error. Also useful when the backend recovers quickly from transient failures.
| Setting | Value |
|---|---|
| Error threshold | 40% |
| Timeout | 3s |
| Reset timeout | 5s |
| Min. calls before tripping | 5 |
HARD_FAIL
The strictest production preset. Trips after very few failures with near-zero tolerance. Use with caution — it can trip on minor blips.
When to use: Zero-tolerance scenarios where even a small number of errors indicates a serious backend issue. Suitable for critical paths where you'd rather block all traffic than risk serving degraded responses.
| Setting | Value |
|---|---|
| Error threshold | 10% |
| Timeout | 2s |
| Reset timeout | 3s |
| Min. calls before tripping | 3 |
TOLERANT
Very slow to trip with generous timeouts. Lets the backend breathe even when it's struggling.
When to use: Slow or unreliable backends (e.g., legacy ERP, SAP instances) where high latency is normal, not exceptional. Also useful for low-risk integrations (e.g., reviews, recommendations) where occasional failures are acceptable.
| Setting | Value |
|---|---|
| Error threshold | 70% |
| Timeout | 60s |
| Reset timeout | 60s |
| Min. calls before tripping | 30 |
Non-production presets
These presets have extremely relaxed thresholds and should never be used in production. EXTREME_DEBUG is automatically blocked in production environments and falls back to BALANCED.
RELAXED_DEBUG
Very tolerant settings for debugging flaky APIs in staging or development. Keeps the breaker open long enough to observe backend behavior without it constantly tripping.
When to use: Debugging intermittent failures in non-production environments. Useful when you need traffic to keep flowing so you can inspect logs and responses.
| Setting | Value |
|---|---|
| Error threshold | 80% |
| Timeout | 30s |
| Reset timeout | 30s |
| Min. calls before tripping | 30 |
EXTREME_DEBUG
Maximum tolerance — the breaker almost never trips. Intended for local development and test environments only.
When to use: Testing only. When you need the circuit breaker infrastructure active but don't want it interfering with your test scenarios.
Blocked in production. If EXTREME_DEBUG is set in a production environment (NODE_ENV=production), the middleware logs a security warning and automatically falls back to BALANCED.
| Setting | Value |
|---|---|
| Error threshold | 95% |
| Timeout | 120s |
| Reset timeout | 60s |
| Min. calls before tripping | 50 |