A circuit breaker
that listens to
your latency.

fluxgo moves its failure threshold in real time using EWMA and tail latency, so it trips early when a dependency degrades and stays calm when it is healthy. It is a drop-in for gobreaker.

Read the docs View on GitHub
Execute() overhead, closed state
~656 ns
on the hot path, every call
0 allocs
fast reject while the circuit is open
~57 ns
API surface with sony/gobreaker
1 : 1

Benchmarks on an Intel Core i5-11300H @ 3.10 GHz, from the fluxgo README.

Static thresholds react late.
fluxgo moves the line as latency shifts.

  • EWMA latency St

    Smoothed mean latency, compared against a healthy baseline learned during warmup.

  • Rolling P95 / P99 Pt

    Tail latency over a fixed window, updated in place with zero allocations.

  • Adaptive threshold θt

    The degradation ratio Dₜ scales the trip threshold, clamped to [θmin, θmax].

  • Stable by design

    Warmup, a minimum dwell time and slow-request classification keep false trips rare.

Drop it in.
Keep your gobreaker code.

Quick start
main.go 
import "github.com/deaprima/fluxgo"

cb := fluxgo.NewCircuitBreaker(fluxgo.Settings{
    Name:   "payment-service",
    Config: fluxgo.DefaultConfig(),
})

res, err := cb.Execute(func() (any, error) {
    return callDownstream()
})
if errors.Is(err, fluxgo.ErrOpenState) {
    // circuit is open — serve a fallback
}
Adaptive threshold
θt = clamp(θbase / Dt)

Dt = W1·(St/Sbase) + W2·(Pt/Pbase)
latency ×2 → threshold ÷2 → trips at half the failure rate

  • fluxgo θt
  • static 0.6 (gobreaker)
  • latency

Same API.
A threshold that thinks.

Aspect gobreaker fluxgo
Trip threshold gobreaker Fixed failure ratio fluxgo Moves with latency (θₜ)
Latency signal gobreaker None fluxgo EWMA + P95 / P99
Slow requests gobreaker Ignored unless they error fluxgo Counted as degraded
Cold start gobreaker — fluxgo Warmup baseline
Flapping guard gobreaker — fluxgo Minimum dwell time
Observability gobreaker Counts() fluxgo Counts() + Snapshot()

Measured, not claimed.
fluxgo vs gobreaker, four failure scenarios.

Each scenario runs 30 times per breaker on a four-service Go chain with injected network faults and steady load. Lower is better for every number.

Normal load

No fault, steady traffic

False trip rate
fluxgo
— %
gobreaker
— %

Results pending

Traffic spike

10 → 250 users with a bandwidth cap

False trip rate
fluxgo
— %
gobreaker
— %

Results pending

Gradual degradation

Latency climbs +50 → +500 ms

Detection delay
fluxgo
— s
gobreaker
— s

Results pending

Sudden failure

Hard timeout at second 60

Detection delay
fluxgo
— s
gobreaker
— s

Results pending

Full results are being collected and will be published here How we measure

Built in the open.
Contributions are welcome.

Make the next slowdown
a non-event.

Get started Star on GitHub