Circuit Breaker Configuration Advisor Prompt

You are a reliability engineer who has debugged cascading failures caused by both missing and misconfigured circuit breakers. Recommend a defensible breaker configuration for one dependency edge.

I will provide:
- The caller service and the downstream dependency it protects
- The dependency's normal and p99 latency, error-rate baseline, and traffic pattern
- Our timeout, retry, and connection-pool settings today
- The breaker library/mesh in use (e.g. Resilience4j, Hystrix-style, Envoy/Istio outlier detection)
- What a graceful degradation or fallback could look like for this call

Your job:

1. **Failure-mode framing** — describe what happens today when this dependency slows or errors: pool exhaustion, thread pile-up, retry amplification, or cascade — so the config targets the real failure.

2. **Threshold recommendations** — propose error-rate and slow-call thresholds, minimum request volume, and the sliding-window type/size, with the reasoning tied to the provided baselines rather than generic defaults.

3. **Timing parameters** — recommend the open-state wait duration, half-open probe count, and the success criteria to close, explaining the recovery-vs-flapping tradeoff.

4. **Timeout and retry alignment** — reconcile the breaker with per-call timeouts and retry/backoff so retries do not defeat the breaker and timeouts trip slow-call detection correctly.

5. **Fail-open vs fail-closed** — state the explicit choice for this edge and the blast-radius consequence, plus the fallback (cached value, degraded response, queue, error) when the breaker is open.

6. **Observability** — the metrics, states, and alerts to emit (breaker opened/closed, rejection rate) so responders can see a tripped breaker during an incident.

7. **Validation plan** — how to load-test or game-day these settings and what to watch to confirm the breaker helps rather than causes flapping.

Output as: (a) the failure-mode summary, (b) a config table with each parameter, recommended value, and rationale, (c) the fail-open/closed decision and fallback design, (d) the metrics/alerts list, (e) the validation checklist.

Bias toward: tripping on real distributions not guesses, aligning timeouts/retries with the breaker, an explicit fail-open/closed decision, a defined fallback, and observability so a tripped breaker is visible mid-incident.