shopify/toxiproxy

:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 19 minutes ago
Added to GitGenius on September 4th, 2026
Created on September 4th, 2014
Open Issues & Pull Requests: 109 (+0)
GitHub issues: Enabled
Number of forks: 510
Total Stargazers: 12,312 (+0)
Total Subscribers: 505 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 260.1 days
Mean response time: 481.0 days
90th percentile: 964.7 days
Tracked items: 13

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 12
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 658 days
Stale 30+ days: 11
Stale 90+ days: 11

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • enhancement (2)
  • ideas (2)
  • Toxiproxy (1)
  • help wanted (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Toxiproxy is a TCP proxy that simulates network and system conditions for chaos and resiliency testing.

The tool addresses the need to test application resilience by dynamically injecting network faults during test execution. Rather than relying on static network configuration or Linux-level tools that require root access, Toxiproxy runs as a standalone proxy that applications connect through. It exposes an HTTP API allowing tests to manipulate connection health on demand, enabling deterministic tampering with specific connections alongside randomized chaos scenarios. This approach lets developers prove their applications handle failures gracefully without single points of failure.

Toxiproxy suits teams building distributed systems who want to verify resilience in development, CI, and test environments without infrastructure changes. The tool works cross-platform and requires no special privileges, making it practical for standard testing setups. It provides toxics—fault injection mechanisms—including latency injection, connection drops, bandwidth throttling, packet loss, timeouts, and connection resets. The framework supports multiple client libraries across different languages, though the core proxy itself is written in Go. The README positions it against existing chaotic proxies by emphasizing the dynamic HTTP API designed specifically for integration and unit testing, contrasting with static tools or Linux utilities that demand root access.

The project maintains active test coverage with continuous integration workflows. Development follows a structured release process with documented upgrade paths for major versions. The codebase includes comprehensive documentation of the HTTP API surface and toxic configuration options, suggesting ongoing attention to usability and backwards compatibility.