The DOI Foundation Status Page

Oct 12, 2026 · resolved Oct 13

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 info@doi.org.

Mar 17, 2026 · resolved Mar 17

At 06:30 UTC on 2026-03-17, after over an hour of substantially elevated traffic, four different servers in the backend of [doi.org](http://doi.org) became unstable approximately simultaneously. These servers collectively provide handle resolution for DOIs maintained by Crossref, the DOI Registration Agency which handles the largest resolution load. [doi.org](http://doi.org) itself continued to function, but resolutions of DOIs maintained by Crossref began to give errors. We received our first notification that something was amiss at 06:38 UTC, but investigation did not begin until a second notification at 07:39 UTC. Restarting the servers did not succeed in removing the instability. There was enough traffic that the servers fell over more or less immediately after restarting. We quickly tightened [doi.org](http://doi.org) rate limiting \(at Cloudflare\) in an attempt to control the traffic, but it did not make enough difference; servers continued to become unstable quickly after restarting. We suspect that the rate limiting might have prevented the issue had it been in place before the traffic surge, with the servers already running, but it didn’t decrease the traffic enough to allow bringing the servers up. We next considered increased resources for servers. This also did not help, at least without further exploration of configuration or software changes. The bottleneck was not directly memory or CPU, but the ability of a each single machine to handle a sufficiently large number of network connections. So we set in motion increasing the number of servers. While waiting on that process, we noticed, belatedly, that the source of the traffic surge identified itself by User-Agent. We blocked that User-Agent string and that reduced the traffic enough to bring the servers online. By 09:30 UTC service was back to normal. **Remaining questions and lessons learned** It’s still not clear exactly what in the nature of the traffic at 06:30 UTC caused such instability. The traffic might have been 5x typical, but that level of traffic happens with some frequency. Some sort of failure cascade seems likely – one machine failed, and that increased the traffic to other machines enough that one more failed, and so on. We have increased the number of backend servers and have made it easier to increase this number again in the future. In hindsight we could have resolved the issue much earlier simply by noticing that the source of increased traffic was easy to block. This is not always the case, but it was the case this time and downtime was increased by failure to take advantage of this quickly. Also, there are other levers at Cloudflare for controlling traffic dramatically, such as to deal with a DDoS attack. It would be unfortunate if some legitimate automatic use of [doi.org](http://doi.org) was temporarily blocked, but it might be preferable to an extended downtime. We have put much effort over the years in increasing the reliability and scalability of the higher levels of [doi.org](http://doi.org) infrastructure, with great success. In that time the backend handle servers have always been rock solid, but it is no surprise that eventually instability due to increased traffic has come for them as well. In the short and medium term we expect that simply having more backend servers will prevent a repeat of this, but we will continue to explore other options as traffic continues to increase.

Nov 18, 2025 · resolved Nov 18

DOI resolutions start at Cloudflare, which provides a number of functions, notably including DDoS protection. The Cloudflare outage on Tuesday is discussed at length at [https://blog.cloudflare.com/18-november-2025-outage/](https://blog.cloudflare.com/18-november-2025-outage/) . DOI resolutions began to be partially impacted as early as 11:30 UTC, although some DOI resolutions continued to succeed for most of the outage. Our internal monitoring alerted us to the problem by 11:50 UTC. Once it was clear that the Cloudflare outage was not going to be resolved quickly, we decided to bypass Cloudflare. This required access to Cloudflare functionality which was itself affected by the outage, but by 13:10 UTC we were able to finalize the bypass. The bypass allowed DOI resolutions to resume within less than 2 hours of the initial issues, instead of the full 3 hour outage experienced by Cloudflare generally. The fact that many of the resources that DOIs point to were also offline, however, meant that the restart of successful resolution may not have been noticeable to all users, as DOI resolution may have succeeded in redirecting them to a document they were still unable to access. Additionally, we found that the bypass did not work for IPv6 traffic; we have resolved that issue should we decide to bypass Cloudflare again in the future. We will continue to monitor DOI use of network services such as Cloudflare and AWS, as we have done for some years now, configuring them to optimize the DOI system. Cloudflare, which is on the whole quite reliable, will continue to be our DDoS mitigation solution for the immediate future, but we will continue to monitor that specific issue in combination with other alternatives.

Oct 17, 2025 · resolved Oct 17

At 2025-10-17 03:08Z lasting for a minute or so, there was a surge of resolution traffic at doi.org at maybe 150x normal traffic. We suspect this may have been a DDoS attempt or a test of a possible DDoS technique. Resolution was impacted for ordinary users of doi.org; as many as 80000 resolution requests (approximately 5% of the apparently legitimate traffic during this time) received various errors, most in the first few minutes but some as late as 03:32Z. Currently resolution is normal but we continue to monitor.

Oct 12, 2025 · resolved Oct 12

The traffic spikes have stopped. We will continue considering ways to prevent this kind of traffic from impacting the use of the system by other users in the future.

Is The DOI Foundation down right now?

No — The DOI Foundation is up. All systems operational as of Oct 18, 2:18 AM UTC.

What is The DOI Foundation's current status?

The DOI Foundation: All Systems Operational. Alert24 checks The DOI Foundation's status page continuously and can notify you the moment it changes.

How do I get alerted when The DOI Foundation goes down?

Alert24 monitors The DOI Foundation and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.