What exactly gets blocked in Spain
On 18 December 2024, Commercial Court No. 6 of Barcelona upheld a claim brought by LaLiga and Telefónica Audiovisual Digital against Spanish ISPs (ruling SJM B 309/2024): while matches are being broadcast, ISPs block the IP addresses that pirate streams come from. According to OONI, such blocks have been observed since February 2025. The blocking is by IP, not by domain and not by SNI. A single Cloudflare edge address serves tens of thousands of unrelated domains, so all the neighbors go down along with the pirates. The court rejected the attempts by Cloudflare and RootedCON to have the ruling annulled; LaLiga announced this on 26 March 2025, stressing that the decision cannot be appealed.
How big this collateral damage is
OONI measured the scale. Of 9.2 million domains tested, more than 554,000 were unreachable from Spain at least once between 1 January and 1 June 2026. Cloudflare accounts for 501,305 of those — 90.4% of all the damage — and it comes from just 2,218 addresses. To take more than 400,000 domains down for an hour, it is enough to switch off between four and twenty IPs. The authors themselves call these numbers a lower bound.
Why it breaks the payment, not the website
For a business, the consequence is not “a customer couldn't open the site.” The Spanish agency WAM, together with Interactiv4, broke down a case in which callbacks from the Redsys payment gateway to stores on Adobe Commerce got caught in the block: the payment went through, but the notification about it never arrived, so orders weren't marked as paid, invoices weren't issued and failed orders weren't canceled. After the notification receiver was moved to a subdomain outside Cloudflare, the share of failed confirmations fell from 48.88% to 1.62%. In OONI's list of what was blocked, s3.amazonaws.com and registry.terraform.io sit next to websites, and in spring 2026 docker pull stopped working across Spain. What breaks is machine-to-machine — the layer where nobody is around to complain.
How to check your own exposure
The check takes an hour. Look at which addresses your domain resolves to, and do the same for the domains that third-party integrations call you from: if both the clients and the webhook receiver sit behind the same edge provider, they go down together. Then lay your ingest failures — ingest being the intake of incoming data — from the past few months over the tournament calendar. In August 2026 our own production service was unreachable from Spain several evenings in a row because of exactly this kind of blocking, while all of its metrics stayed green.
What to do about it
- Move the receiver for machine notifications — webhooks, payment callbacks, ingest — to a separate subdomain with a separate route, not behind the edge address it shares with the website.
- Keep your own event log on your side and a periodic reconciliation alongside the webhooks: whatever didn't arrive during a block is exactly what the reconciliation will pick up.
- If you have clients or contractors in Spain, check the tournament schedule as part of your release calendar — it's cheaper than picking an incident apart after the fact.
This boundary is a special case of a broader rule: automation built on top of someone else's platform inherits its points of failure along with it. The full list of commitments your vendor never took on is covered in a companion note, linked below.