Circuit Breaker Laravel Package

Product Decisions This Supports

• Build vs. buy for resilience plumbing. A circuit breaker (fail-fast after repeated downstream failures, with half-open recovery probes) is well-understood, low-differentiation code. This package lets you buy that logic instead of building it, so roadmap time stays on customer-facing work rather than on retry/backoff state machines.
• Reliability roadmap sequencing. If your product depends on third-party APIs (payments, shipping, KYC, LLM providers, email), a breaker is the cheapest lever to stop one flaky dependency from cascading into timeouts, thread/worker exhaustion, and 500s. This supports prioritizing "graceful degradation" over "more infrastructure."
• Feature framing for degraded-mode UX. Once breakers exist, product can decide what the user sees when a dependency is down — cached data, a queued "we'll follow up" flow, or a scoped error — rather than inheriting whatever a raw exception produces. This package is the enabler for those product decisions.
• Framework-upgrade planning. v1.8.1 adds Laravel 13 support. That is a compatibility signal, not a feature: it means adopting this package does not add a blocker to a future Laravel major upgrade. Relevant if your platform team has a standing "no packages that pin us to an old major" rule.
• Not a decision this supports: SLO/error-budget policy, observability strategy, or queue/retry semantics. Breakers complement those; they don't replace them.

When to Consider This Package

Consider it when:

• You make synchronous outbound calls to a dependency that has real outage modes (not just occasional 500s), and a stalled dependency can tie up PHP-FPM workers or queue consumers.
• Your codebase already has ad-hoc resilience logic scattered across services — a shared abstraction is a net simplification.
• You want a Laravel-native implementation (facade/service-container integration, config-driven thresholds) rather than pulling in a framework-agnostic library and writing the wiring yourself.
• You are on, or planning, Laravel 12/13 — v1.8.1 explicitly covers the L13 path.
• Your team is small enough that "a few hundred lines we don't maintain" is worth more than total control.

Look elsewhere (or build ~150 lines in-house) when:

• Dependency health is already observable and you'd rather drive traffic decisions from metrics than in-process counters. Breakers keep state per-process/per-node; with many PHP workers your effective thresholds get fuzzy, and a centralized/shared-state approach (Redis-backed, or gateway-level via a service mesh / Envoy outlier detection) may be more honest.
• You need breaker state shared across pods. Verify this package's state backend before assuming it does; in-process state across N workers behaves differently than a single-process breaker.
• Very low call volume to the dependency — breakers need enough traffic to distinguish "down" from "slow," and you'll mostly get noise.
• Maintenance risk tolerance is low. This is a small, single-maintainer project; v1.8.1's Laravel 13 support came from a first-time outside contributor, which is a positive community signal but also an indicator of a thin maintainer bench. If your org requires active security response and long-term support, weigh that.
• You need async/worker-pool semantics (Octane/Swoole long-lived workers) — confirm state reset behavior between requests explicitly.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have several features that break completely when a third-party provider has a bad day. This package is a small, standard piece of plumbing that makes those failures fail fast and predictably instead of hanging our servers and degrading the whole product. It's cheap, it's a well-known pattern, and the latest release keeps it compatible with our Laravel upgrade path. Recommendation is a timeboxed evaluation in one integration, not a platform-wide rollout.

For engineering (the real pitch): algoyounes/circuit-breaker gives us a Laravel-native breaker so we stop reimplementing retry/threshold logic per integration. v1.8.1 is a compatibility-only patch — Laravel 13 support, no API changes, no breaking changes, no deprecations — so the upgrade risk is essentially zero and it doesn't constrain our framework roadmap. Two caveats to validate in a spike: (1) where breaker state lives and how that behaves across multiple workers/pods and under Octane, and (2) bus-factor — it's a small project, so we should treat it as a thin abstraction we could vendor or replace in a day, not a deep dependency. Proposed next step: wrap one non-critical outbound integration, instrument it, and confirm the breaker trips on a simulated outage before we touch anything payment-critical.