BreakerMachines is a production-ready circuit breaker for Ruby/Rails with built-in async/fiber support, fallback chains, and rich monitoring. Unlike existing gems, it handles modern Ruby's fiber scheduler and avoids dangerous thread timeouts.
I’m usually weary of long readmes with too much styling as that indicates to me a high likelihood that they were written by ai and the author might not have even read all of it. The use of generic ai images also gives a bad impression - for example, there’s an image captioned “The green lines? Those are your CPU cycles escaping.” without anything green pictured.
I’m not saying your gem is bad. It’s nice to se an attempt at a circuit breaker that is based on the state machines gem, I will certainly look into the actual code if I have a need for it in the future.
Just wanted to give you this bit of feedback about maybe cutting down on length and loosing the ai images in the readme as I think it might be a turnoff for others as well.
Appreciate the feedback—really.
You are correct to point out the mismatch on the image caption, i generated a few and copied the wrong one. That one's on me, i will update it later.
And while AI might correct a typo or help rephrase a sentence here or there (I’m not a native English speaker), everything in that README—tone, structure, content, rants, and lore—is 100% me. It's my style. Love it or leave it.
As for scaring people off ? That’s not a bug, that’s a feature. This is an open source circuit breaker, not a SaaS onboarding funnel. If someone decides not to use a well-tested library because the README isn’t sterile enough for their corporate taste, that is their loss. I'm not here trying to win two potential enterprise clients who expect a PDF pitch deck and a hug.
The circuit breaker pattern itself isn’t new, I didn't invent it, it has even its own wikipedia page. But the Ruby ecosystem? Still treating it like a nice to have.
Existing circuit breaker gems like Circuitbox, Semian, etc., are stuck in the past. They rely on patterns and syntax from the Ruby 2.6 era, and integrating them into a modern codebase often means a painful refactor or bending your architecture backwards. BreakerMachines is built for 2025, fully async, fiber-safe, and designed to work with modern Ruby without dragging a legacy ball and chain. It's don't even support version of ruby that is 1 version behind. Upgrade then use.
If someone is going to get frustrated by a long README or AI-generated images, they’re welcome to go pay someone to write them a handcrafted if/else block and call it resilience.
The code is clean. The tests are good. And if just that MD file makes them walk away from that—again, their loss. They don't even read it.
I maintain a ton of gems. And I’ll be honest: my enthusiasm for open source has been repeatedly drained by the "please make this more corporate-friendly" crowd. Not talking about you specifically—but there’s a whole wave of people who want everything politically polished and personality-free. That’s not why Ruby was created.
Ruby was made for joy. And this gem? It reflects that.
Cheers for actually reading and for giving honest feedback. You’re rare for that. Just don’t expect me to dress up like a SaaS salesperson anytime soon.
I did split the readme now. Thank you again.
Hey HN! I extracted BreakerMachines from my apps after seeing people dealing with cascading failures in production Rails apps.
Key features that set it apart:
- True async/fiber support (works with Falcon, async gems)
- Built-in fallback mechanism with chaining
- Thread-safe without dangerous Timeout.timeout
- Memory-efficient with WeakRef tracking
- Rich introspection and monitoring hooks
- Clean DSL that works with inheritance
With everyone adding AI/LLM APIs to their apps, circuit breakers are more critical than ever.
These APIs can be slow, flaky, or have outages - without protection, your app goes down with them.
The README shows patterns for graceful degradation when a service is down.
I explicitly avoided shipping Redis/DB adapters to keep it focused, the README shows how to implement your own in ~20 lines.
Would love feedback on the API design and any edge cases I might have missed!
I'm still going to add the parallel feature, i removed it because i need to test it in CI.