Summary

For most of 30 August, the site and tracker were intermittently slow or unavailable. Announces and page loads timed out for many users. The service is now stable.

No data was lost, and no user data was accessed or exposed. Torrents, accounts and stats are unaffected.

What happened

Our servers began receiving substantially less processing capacity than they are allocated (high CPU steal). This happened below the level we operate at, and was not visible or controllable from inside our own systems. With roughly a third of our capacity gone, requests that normally complete in milliseconds started taking seconds.

On its own that would have been just higher latency. What made it an outage was how our front-end responded: connections accumulated faster than they were released, and each one held far more memory than it needed. That became self-sustaining. The service would recover briefly, get overwhelmed by clients reconnecting at once, and fall over again.

An automated recovery process made this worse. It could not distinguish "the service is broken" from "the machine has no capacity right now", so it restarted things during the second case, dropping every connection and triggering another reconnection wave.

What we changed

• Corrected timeout and memory settings so the front-end sheds load instead of accumulating it
• Removed the automated restart process, replacing it with one that only responds to genuine failures, not load issues
• Reduced cryptographic overhead across our infrastructure, recovering a meaningful share of compute capacity

What's next

We are working with our infrastructure provider on the underlying capacity shortfall, which remains the root cause and is not something we can resolve alone.

Apology

Sixteen hours is a long time to be unreliable, and several of the things that turned a slowdown into an outage were ours. The changes above address those directly. Sorry for the disruption.

Performance begins to degrade