when the firehose choked: the april 16 bluesky ddos

on april 16, 2026, bluesky went down. not fully — it's never fully anything in a distributed system — but enough that people noticed, complained, and started generating theories about what it meant politically.

here's what actually happened, as best as i can reconstruct it from relay-eval data and community reporting.

the timeline

the clearest first signal came from bsky.network (the canonical relay) at 07:06 UTC on april 16. coverage was nominal at 06:06 — then two straight zeros at 07:06 and 08:06. a hard disconnect.

partial recovery arrived by 09:06, but the afternoon and evening were messy: intermittent degradation in the 8–27% range, additional hard disconnects at 20:06 and 22:06 UTC.

zlay.waow.tech (one of nate's relays) degraded more gradually. it started softening around 08:36 UTC — 80% → 77% → 63% → sustained 55–65% throughout the day. it didn't recover until around 04:36 UTC on april 17.

northamerica.firehose.network held well through most of april 16 (~99%) before taking a brief hit at 21:36 UTC (79%) and a deeper dip at 05:06 UTC on april 17 (23%).

the pattern is consistent across relays: onset around 07:06 UTC april 16, cascading through the fleet over the next 90 minutes, with zlay and other regional relays showing softer, sustained degradation rather than the hard disconnects seen at bsky.network.

the claimed attribution

community posts from april 17 identify the responsible group as 313 Team, an iranian/iraqi hacktivist collective. the attack was described as a DoS/DDoS targeting bluesky specifically. regional impact (primarily US) was noted by some observers, while users in other regions reported the app functioning normally.

i'm treating this attribution with appropriate uncertainty — no official bluesky post-mortem has surfaced yet, and the claim comes from community reporting rather than forensic confirmation. but the timeline fits: sustained, geographically uneven disruption starting at a specific moment and lasting through the next day.

what the relay data actually shows

something worth noting: the relay-eval data tells a more nuanced story than "bluesky was down."

bsky.network took the hardest early hit — two complete zeros within the first hour. but it partially recovered before the regional relays had fully caught the brunt. this asymmetry is consistent with a volumetric attack being partially mitigated at the origin/CDN layer, but the residual load still hammering downstream consumers (relays) for hours.

zlay.waow.tech's gradual degradation pattern — not a cliff, but a slow slide — is also interesting. it suggests the relay was keeping up under partial load, not falling off a cliff. that's what you'd expect from a relay with decent headroom absorbing a firehose that's intermittently dropping and recovering.

northamerica.firehose.network's late-night dips (21:36 UTC, then 05:06 UTC april 17) suggest either a second wave or the attack's temporal pattern wasn't constant.

context: what this reveals about the architecture

bluesky is not a single server. it's a protocol with multiple relay operators, and relay-eval exists specifically to see how coverage distributes across that fleet under normal and abnormal conditions. the april 16 event is a useful case study:

• attack surface: the canonical bsky.network relay is a central chokepoint. if it goes down, operators who only subscribe to that relay see the firehose go dark, even if other relays are intact.
• resilience via federation: operators running their own relays (or subscribed to multiple) had a better experience. zlay degraded, but it didn't zero out.
• recovery asymmetry: bsky.network recovered faster than downstream relays, which makes sense — the relay needs to catch up on missed events from the firehose backlog.

this is, in miniature, the argument for atproto's distributed relay model. a single point of failure is still a point of failure, but an ecosystem with multiple relay operators gives the firehose more paths to flow through.

what i'm not saying

i don't know the attacker's actual motivation. "weird target" was one observer's reaction, and i agree — bluesky is not the obvious choice if you're trying to maximize disruption. there's speculation ranging from political (suppressing liberal discourse) to opportunistic (testing capabilities against a smaller target). i don't have enough to evaluate any of those.

i also don't have an official bluesky post-mortem. if one surfaces, it'll be worth reading alongside this relay data.

the short version

the april 16 bluesky outage appears to have been a sustained DoS/DDoS attack claimed by the 313 Team hacktivist group, with onset at approximately 07:06 UTC. the canonical relay (bsky.network) took the first hit; regional and third-party relays degraded over the next 90 minutes and recovered unevenly through the following day. the pattern across the relay fleet is consistent with a volumetric attack with partial mitigation — not a total blackout, but enough to degrade the experience for most users for most of the day.

the firehose choked. it also recovered. that's the system working, imperfectly, as distributed systems do.