Problems resolving DOIs almost entirely for automated users

Update timeline

1. identified Oct 12, 2026, 03:07 AM UTC

   Due to a sudden large spike in traffic -- either a DDoS attempt or a unfriendly bulk DOI resolution -- some DOI resolution would have failed on Sunday evening / early Monday morning. Affected regular users were mostly automated traffic, but a smaller amount of human browser use of doi.org would also have been affected. We are taking steps to identify and control the traffic.

2. resolved Oct 13, 2026, 05:17 AM UTC

   This incident has been resolved.

3. postmortem Oct 13, 2026, 05:18 AM UTC

   On October 11th and 12th [doi.org](http://doi.org) experienced three large traffic spikes: from 22:30 to 22:40, 23:51 to 00:04, and 01:47 to 02:33. In one particular region traffic was 20x to 25x normal during the incident. Users who accessed [doi.org](http://doi.org) in other regions were unaffected. In the affected region, we believe load shedding mostly kept the system stable for non-automated users. But many automated users would have had legitimate requests rejected during the incident. A smaller number of non-automated users would have hit an error, which probably was resolved simply by reloading the page. Considering the largest part of the spike 02:00 to 02:35, out of 4M requests not from the source of the traffic spike, 172k were automated requests that were rejected by the load shedder as part of maintaining system stability, and almost 4k were automated or non-automated requests that failed either due to the load shedder or transient instability. It’s often not entirely clear whether a traffic spike represents an attempted DDoS attack or simply an overzealous bulk DOI resolution activity. In this case, looking again at the 02:00 to 02:35 time range, there were 18.8M requests apparently from the source of the traffic spike, of which 6M were rejected by load shedding; of the remaining 12.8M, 11.1M were DOI Not Found. That does seem that it may indicate an attempted DDoS attack. Although load shedding would eventually give way to just scaling to absorb the traffic, in this incident we decided to use Cloudflare facilities to challenge the apparent source of the traffic. This would allow non-automated traffic \(a human at a browser\) but would generally not allow automated traffic. We believe that “legitimate” automated traffic is unaffected by this. The attack, if that is what it is, has continued, but Cloudflare is absorbing it – at a rate of over 9M requests per minute shortly after we instituted the challenge, but averaging closer to 1M requests per minute over the past day. We will continue to monitor this. If you have automated traffic to doi.org that you believe is being adversely affected by the current configuration, please send a message to [email protected].