The DOI Foundation Status Page

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.

May 29, 2024 · resolved May 29

The [doi.org](http://doi.org) resolution downtime on 2024-05-29 was caused by a sudden disappearance of our access to Cloudflare’s “Load Balancing” product. This has been used by [doi.org](http://doi.org) to steer traffic based on location to appropriate backend servers. We were not able to re-enable “Load Balancing” and found a workaround using AWS services, eventually AWS “Global Accelerator”. We opened a ticket with Cloudflare at that time, but after three weeks we have not received any useful information from them. During this time, Cloudflare has noted an issue with billing and subscriptions at [https://www.cloudflarestatus.com/incidents/5t270n2ndf0h](https://www.cloudflarestatus.com/incidents/5t270n2ndf0h) . We suspect that our issue is related to this, and just happens to have been perfectly organized to result in a loss of service. Although widespread billing issues may explain Cloudflare’s lack of response to our ticket, we find it disappointing, especially given that we had actual service downtime as a result. We have decided to make our use of AWS “Global Accelerator” permanent. For [doi.org](http://doi.org), this service is significantly less expensive than Cloudflare’s “Load Balancing”, and even seems to have a small positive effect on latency. We are still using Cloudflare services also, especially for rate limiting and potential DDoS mitigation. We will continue to monitor our Cloudflare subscriptions, billing, and tickets for any new issues or any explanatory information. And we apologize for the inconvenience caused by this downtime.