Over the past few weeks, many users have noticed that Zenodo is slower than usual. Pages and searches may take longer to load, and uploads and downloads may sometimes fail or take longer than expected.

We understand that this can be frustrating, particularly when working with Zenodo as part of research workflows.

This post provides an update on the current situation and what we’re doing about it.

Why is Zenodo slow?

Zenodo continues to grow, both in the amount of research it hosts and in the number of people and services accessing it.

Following our January 2026 update, we made improvements to and scaled up Zenodo’s infrastructure, which helped address the immediate performance issues for several months. Since then, continued growth in demand, together with an increase in automated traffic, has created new performance challenges.

The graph below illustrates the sustained increase in incoming requests to Zenodo over time. This higher traffic volume, together with changes in the nature and distribution of requests, is putting additional pressure on the service.

Increase in incoming requests to Zenodo over time

This automated traffic includes crawlers, harvesters, AI-related systems, and other automated clients accessing Zenodo at high frequency. It puts significant pressure on the service and affects performance for many users. Infrastructure scaling alone is no longer sufficient, so we are now working on the next set of measures to improve Zenodo’s performance and resilience.

Because Zenodo is an open service, we want to keep its content accessible and reusable for all users. Our goal is therefore not only to make Zenodo faster, but also to make it more reliable when demand is high.

What are we doing?

We are working on several improvements in parallel.

1. Improving Zenodo’s software: We are continuing performance work in the Zenodo codebase, including:

   1. upgrading to Python 3.14
   2. working through a number of application-level performance improvements, such as identifying and reducing expensive operations in the application. Where possible, these improvements will be implemented in InvenioRDM, the underlying digital repository technology, so that Zenodo and other InvenioRDM adopters can benefit from the improvements.

2. Improving traffic management: We are improving how we identify and manage different types of traffic to Zenodo. This includes fine-tuning rate limits and better identifying the sources of incoming requests, allowing us to apply appropriate measures based on the type and volume of traffic while keeping legitimate use responsive. Read our Search API update.

3. Improving bulk access: To support large-scale reuse of Zenodo metadata without putting unnecessary strain on the live service, we are developing exporter dumps and other bulk-access mechanisms.

   This will help us provide responsive access for researchers while making large-scale harvesting more efficient and sustainable.

4. Testing additional protections: We are testing targeted Proof-of-Work challenges to help distinguish normal browser traffic from certain forms of automated access.

   These measures will be applied selectively and carefully to avoid creating unnecessary barriers for researchers, accessibility tools, and legitimate integrations.

5. Working with CERN and the wider community: Zenodo is operated within CERN’s infrastructure, and discussions are ongoing with CERN teams about the wider traffic situation.

   We are also sharing knowledge with partners in the InvenioRDM community to better identify and filter problematic automated traffic earlier.

What do users need to do?

If you use Zenodo interactively to search, browse, deposit or download research outputs, some operations may take longer, but you do not need to change how you use the service.

If you operate a crawler, harvester, AI system or other application that makes large numbers of requests, please respect Zenodo's published rate limits, use bulk-access options where available and use a clear and identifiable User-Agent. We recommend a format such as “AppName/1.0 (+https://example.com; contact@example.com)”, which allows us to identify the source of traffic, apply appropriate measures or contact you in case of need. To prevent automated abuse, high-volume requests using generic User-Agents (such as default "curl" or "python-requests") may be rate-limited or blocked. We strongly encourage adding a custom User-Agent string to your scripts.

For large-scale metadata access, please use services such as OAI-PMH, metadata dumps and other mechanisms designed for this purpose rather than repeatedly querying the interactive Search API.

This helps keep Zenodo available and responsive for everyone.

What happens next?

This is ongoing work. In the short term, we are continuing to improve application performance, tune rate limits and mitigate excessive automated traffic. In parallel, we are developing longer-term improvements to make Zenodo more resilient as the service continues to grow.

Our objective is not simply to get through the current period of high load, but to build a service that remains reliable and responsive as the scale and nature of demand continue to change.

We will share further updates as significant improvements become available.

Thank you for your patience, feedback and continued use of Zenodo.

Smarter setup for your EU project community

Setting up a new EU project community is now simpler thanks to the EU projects database CORDIS and the OpenOrgs database.

When creating a new project community on the EOR, key information is now populated automatically, including:

• a project short description;
• links to the project's website;
• participating organisations.

EU project community form with additional fields populated automatically

Automated curation, better metadata quality

A new set of automated curation checks help improve the metadata quality of your records in your EU project community:

Record submission checks validate funding information by comparing metadata against your project’s description.

Project community checks validate funding information, detect existing project communities to avoid duplications, verify the presence of required project metadata (including website, logo, and participating organisations), and verify members' affiliations with your community.

These enhancements will guide you towards creating high-quality metadata submissions while supporting compliance with Horizon Europe Open Science requirements. Together, this will speed up about 40% of curation tasks that were previously carried out manually!

Record submission check

Learn more about our approach to AI in our new dedicated page, which explains how AI is used, how data is processed, and how these checks are applied consistently to all submissions to ensure a fair and harmonised curation process.

Archive and preview websites in Zenodo

A WARC (Web ARChive) previewer has been enabled in Zenodo. This new feature, developed by our collaboration partners directly in InvenioRDM, allows users to preview and inspect archived web content directly within the repository.

Web ARChive previewer

Learn more

Did you miss the OpenAIRE webinar on the European Open Research Repository? You can rewatch the session on YouTube and learn more about the EOR!

Stay Connected & Informed:

• Subscribe to our newsletter.
• Explore the updated documentation pages.

On May 15, 2026, the Zenodo team identified and resolved a web caching misconfiguration that temporarily exposed user sessions to other active users visiting specific URL pathways.

• Incident start: May 13, 2026, at 15:30 CEST (13:30 UTC)
• Incident resolution & fix applied: May 15, 2026, at 15:15 CEST (13:15 UTC)

We take data privacy and platform security seriously. Below is a transparent breakdown of what happened, the limited scope of the impact, how we resolved it, and what it means for your account.

Why was the change made?

Zenodo has experienced a dramatic increase in platform traffic, driven in large part by automated traffic and AI scrapers/bots (see also our recent blog post). To ensure we continue providing a high-quality, fast, and responsive service to our research community, our team has been actively optimizing and scaling our infrastructure to cope with this high load.

Unfortunately, during one of these infrastructure scaling adjustments to our web caching, an unexpected configuration error was introduced.

What happened?

While adjusting our caching rules to better handle heavy automated traffic, we incorrectly configured the ones for the DOI badge images, visible in the record landing pages.

Instead of serving a static badge image, the caching layer inadvertently cached the active session state (anonymous or authenticated) of the user requesting it. As a result, if a subsequent user visited a record landing page that triggered that specific badge path, they were accidentally served the session of the previous user, effectively impersonating their account. In practical terms, for as long as a session was mixed up, the other person could see and do the same things the account owner could while signed-in.

Users navigating the site during these 48 hours may have experienced:

• Being suddenly logged out of their account.
• Finding themselves temporarily logged into another user's account.

User reports of unexpected account behaviour during this period confirmed our analysis of the access logs.

Impact analysis

We analysed approximately 5.8 million HTTP access log entries from our monitoring systems and cross-referenced them with every affected account.

Our findings show that the real-world impact was largely contained:

• Approximately 3,000 accounts had their session reused by a different IP address. Because a signed-in user's email address is shown in the account menu, that email address may have been visible to another person in roughly 2,200 of these cases. In a smaller subset, other account settings pages were opened, which also show full name, e-mail, affiliation, and linked accounts.
• One user accidentally modified personal information of another account. Both accounts have been fully restored, no credentials or tokens were leaked.
• One user accidentally published a record on behalf of another user due to a cached session. The issue has been solved.
• A limited number of users connected their external login to the wrong account. All wrong accounts have been unlinked.
• No users generated shared links or granted permanent unauthorized access to restricted records.
• For 221 records that have restricted files, the in-browser file preview could have been shown to another person holding the owner's session, and for some of these a preview was opened. We confirmed that none of these restricted files were downloaded.

Where we were able to follow up with the users involved, they confirmed that these actions were accidental.

Actions taken

As soon as the bug was identified, we took Zenodo offline for about 45 minutes on May 15. The faulty caching rule was completely removed and we invalidated all active user sessions, logging everyone out and immediately terminating any lingering or mixed sessions.

As a strict precautionary measure, all private access tokens created during the 48-hour incident window have been permanently revoked.

All affected users have been contacted. In line with our data-protection obligations, we assessed the incident together with our Data Protection Officer and agreed on the scope and the actions described here.

Frequently Asked Questions (FAQ)

Do I need to change my password or tokens?

No. Passwords and tokens are encrypted and are never exposed in plain text.

Why did my API/Personal Access Token stop working?

If you generated a Personal Access Token between May 13 (15:30 CEST) and May 15 (15:15 CEST), we proactively revoked it to protect your account. You simply need to go to your profile settings and generate a new token. Tokens created before or after this window are completely unaffected.

Was my restricted data accessed?

No restricted files were downloaded, which was confirmed from our access logs. For a number of records with restricted files, the in-browser preview, which shows part of a file, may have been visible to another person during the window. If you own one of these records, we have contacted you directly with the details.

I noticed a strange change on my account or a duplicate record. What should I do?

If you still see something unexpected that occurred strictly during the May 13–15 window, please contact us on support.

How do I know if I was affected?

If you were affected, we have emailed the address on your account. If you did not receive an email from us about this incident, you were not in the affected group.

We sincerely apologize for this incident and any confusion or concern it may have caused. While it is essential to adapt our infrastructure to handle modern web and AI traffic, we are reviewing our internal staging and testing procedures to ensure traffic-handling updates undergo stricter isolation rules before reaching production.