On October 28, mirror 03 logged a two hour window where response times climbed well above baseline. The median round trip time for that node sits at 2.1 seconds under normal load. During the spike, page loads stretched past 20 seconds and some image assets failed to render on first attempt. No user data was lost, no orders were voided, and the escrow timers kept counting as usual.
How it was detected
Detection came through our passive monitoring hooks. We watch the handshake phase of every Tor circuit before it reaches the application layer. At 09:42 UTC, the average latency across six consecutive probes crossed 4.5 seconds. That threshold triggers a manual look without alerting the whole base. By 09:48 we confirmed the slowdown was localized to one node, not a network wide event.
Resolution
The cause was a routing quirk inside the onion service itself. A transient packet reordering pattern forced clients to wait for out of order fragments. We flushed the local buffer cache at 11:40 UTC and the median rtt settled back to 2.1 seconds by 11:52. Total elapsed disruption: roughly two hours.
What to take from it
If you ever see content loading slowly but not failing entirely, wait before reloading aggressively. Hard refreshes during a latency event can actually extend the visible delay because they restart the handshake mid stream. One patient reload after thirty seconds beats five impatient ones.