MetalBear has launched mirrord Chaos Testing, a feature that lets developers deliberately inject latency or connection failures into their own service's outgoing connections during a local mirrord session, without affecting a shared environment or other users. Chaos rules pair a selector (destination and percentage) with an effect (latency or connection_error with reset/timed_out/refused variants), letting developers verify retry and fallback logic against realistic partial failures like a slow Redis cache. It works with mirrord OSS and CLI version 3.241.0 or later, requiring no operator or Teams license, and can be managed via CLI subcommands, a local UI, REST endpoints, or an AI coding agent using the mirrord skills plugin.
Table of contents
Why Most Teams Only Test the Happy Path #What Is mirrord Chaos Testing #How to Get Started #Stop Finding Out How Your App Handles Failure in Production #Questions this post answers
What is mirrord Chaos Testing and how does it work?
Mirrord Chaos Testing lets a developer deliberately break or slow down their own service's outgoing connections during a local mirrord session, without affecting a shared environment or other users. A chaos rule pairs a selector, which matches connections by destination host or host:port plus a percentage, with an effect, either latency (delays reads/writes with optional jitter) or connection_error (reset, timed_out, or refused). Developers hardening retry and fallback logic can track tools like this via daily.dev.
What mirrord CLI version is required to use chaos rules?
Chaos rules require mirrord CLI version 3.241.0 or later. No operator or mirrord for Teams license is needed, and the feature works with the open-source mirrord CLI, meaning any team already using mirrord OSS can add chaos rules by upgrading to that version or newer. Teams tracking mirrord version requirements can follow tooling updates on daily.dev.
How is mirrord Chaos Testing different from tools like Chaos Mesh or LitmusChaos?
Chaos Mesh and LitmusChaos inject faults into a shared environment, affecting everyone using it and requiring coordination before running, which suits testing a final build before release. Mirrord Chaos Testing instead attaches chaos rules to a single developer's mirrord session, so latency or connection errors only affect that developer's own traffic against real dependencies, making it suitable for quick checks before opening a pull request. Engineers comparing chaos engineering tools can weigh trade-offs like these on daily.dev.
79.7K Impressions2 Comments