Risks of Eventlet

If you are already convinced that you have to migrate off of Eventlet, then you can simply skip this chapter and jump directly to the next one, else, you are at the right place.

Arguments Against Eventlet 🔗

It do not matter if you are a a developer, a project owner, a planning maker, or a business owner, everyone will find what they are looking for in the arguments set out below.

Eventlet is a Legal Danger 🔗

Using obsolete and poorly maintained technologies, such as Eventlet, exposes companies to increased security vulnerabilities, thereby compromising the protection of personal data of their product users and their compliance with the GDPR and with data protection authority rules. In many cases, companies have been ordered to pay millions of dollars by courts around the world (USA, Europe) due to a security breach in their systems. Data protection authorities, like the CNIL in France, often have the power to impose financial penalties reaching several million euros or, in the case of a company, up to 4% of its annual worldwide turnover.​

Obsolete technologies are more likely to contain unpatched vulnerabilities, increasing the risk of unauthorized access to personal data. The GDPR and data protection authorities require companies to implement appropriate measures to ensure the security of personal data, and failure to comply with these obligations can lead to severe sanctions.​

However, by adopting modern and well-maintained technologies, training staff in cybersecurity, and conducting data protection impact assessments, companies can significantly reduce these risks. It is therefore strongly recommended that companies avoid using obsolete technologies like Eventlet and adopt modern, well-maintained solutions to ensure the security of personal data.​

Failing to remove Eventlet from your products exposes your business to legal penalties, for which you could be held personally liable in court.

Eventlet is a Productivity Killer 🔗

The use of Eventlet reduces the efficiency of development and maintenance teams by increasing cognitive load, debugging time, and coordination efforts. Due to monkey patching, standard libraries exhibit unpredictable behavior, forcing developers to spend considerable time identifying and fixing hard-to-trace bugs. Additionally, learning Eventlet presents an unnecessarily steep curve for both newcomers and experienced developers, requiring them to invest time in an obsolete tool.

This complexity leads to a fragmentation of skills within teams. Collaboration is also affected, as developers must document and explain the side effects of monkey patching, which burdens communication and disrupts workflow fluidity.

An efficient team must rely on predictable, well-documented tools that are widely adopted by the community. The more uncertainty and friction a tool introduces, the more it slows down collective execution. Projects that have already migrated away from Eventlet report a significant reduction in time spent managing anomalies and maintaining their code, allowing them to focus on higher-value tasks. Likewise, onboarding new developers becomes easier, accelerating their learning curve and integration into the team.

Some may argue that Eventlet still works and that the migration cost would be too high. However, a tool that "works" while reducing team efficiency ultimately hinders productivity. The hidden cost of time lost dealing with unpredictable behavior is far greater than a well-planned, gradual transition to a modern alternative. A carefully phased migration would allow teams to progressively reduce their dependence on Eventlet without disrupting their daily work while improving their efficiency right away. That's the goal of this guide.​

Failing to remove Eventlet from your products destroy the productivity of your team.

Eventlet is An Ethical Problem 🔗

The continued use of Eventlet constitutes a failure to protect users, as it exposes their sensitive data and infrastructures to avoidable security risks. Due to its reliance on monkey patching, Eventlet dynamically modifies the behavior of standard libraries, introducing unpredictable and hard-to-detect side effects. This instability can lead to data leaks, service disruptions, or even exploitable security vulnerabilities. A user relying on your Eventlet based project to store critical data—such as personal information, medical records, or financial transactions—could see their data compromised without any way to protect themselves, simply because the platform is built on outdated technology.

The consequences of a security breach are severe for end users. Losing control over their data can result in privacy violations, identity theft, or even significant financial losses. If a vulnerability in Eventlet were to be exploited, it could have an irreversible impact on user trust in your products and all services that depend on it.

Recent history has shown that neglecting outdated technologies has already led to disasters. In 2014, the Heartbleed vulnerability in OpenSSL allowed attackers to extract sensitive data for years without users realizing it. In 2021, the Log4Shell vulnerability led to massive intrusions, affecting thousands of critical systems simply because a widely used library had not been updated. In 2017, the attack on Equifax exposed the personal information of 140 million people due to the use of an outdated version of Apache Struts containing a known critical flaw.

Keeping Eventlet in place means accepting the risk that one day, a similar incident could impact your projects and its users. Some may argue that no major attack related to Eventlet has been reported yet and that removing it would come at a significant cost. However, waiting for a disaster to happen before taking action is irresponsible. A security flaw can go unnoticed for months or even years, and by the time it is exploited, it is often too late for the victims.

A well-planned migration, like the one proposed in this guide, would allow teams to gradually reduce reliance on Eventlet without disrupting users, while ensuring a level of security and reliability that meets their legitimate expectations. Continuing to use Eventlet is a conscious decision to expose users to data breaches and consequences they cannot anticipate or prevent themselves.

Continuing to use Eventlet is like knowingly putting passengers on a defective plane — it might stay in the air for now, but a crash is inevitable. Choosing to ignore it is both unethical and irresponsible.

Eventlet Destroy the credibility of your projects 🔗

The use of Eventlet degrades the user experience by making application performance unpredictable and causing sudden interruptions, leading to frustration and a loss of trust among end users.

Users expect consistency and responsiveness when interacting with a service, yet with Eventlet, they may experience smooth performance at one moment, only to face unexplained slowdowns the next, even under similar conditions. This inconsistency stems from Eventlet’s inefficient thread and I/O management, which can cause some requests to be delayed unpredictably. Worse still, Eventlet’s reliance on monkey patching introduces unforeseen behaviors and hard-to-trace errors, leading to sudden crashes that interrupt user actions without warning. As a result, users may lose progress, face downtime, or experience disruptions at critical moments, all without any clear explanation.

A great user experience depends on reliability and predictability. A product that behaves inconsistently and interrupts users unexpectedly erodes trust and causes frustration. Users expect the services they rely on to function smoothly and predictably without having to worry about technical failures behind the scenes.

When applications become unstable, users abandon them. Studies in user experience (UX) show that inconsistent performance and random failures are among the top reasons users stop using a service. Even if an application works well most of the time, occasional unexplained failures create a negative perception that is difficult to erase. Additionally, unreliable applications generate a flood of customer complaints and support tickets, increasing operational costs and overloading technical teams.

Some may argue that Eventlet’s instability is tolerable since it doesn’t always manifest and that workarounds exist. However, the real problem is not systematic failures but unpredictable ones—users might have a seamless experience today and a terrible one tomorrow, which is even more frustrating than a consistently slow service. Furthermore, existing fixes only mask the symptoms without addressing the root cause. No amount of patching can change the fundamental fact that Eventlet is an outdated and unreliable technology.

If immediate removal is not feasible, a structured plan to phase out Eventlet must be put in place to ensure a stable and predictable user experience, that's the goal of this guide. Ignoring this issue means knowingly accepting a degraded user experience and exposing end users to frustration, lost productivity, and service disruptions—none of which are acceptable in a modern application.

Would you buy a product that is known not to work?

What Are Our Motivations 🔗

We are the core maintainers of Eventlet. We argument against the product we maintain. Do not get us wrong, this is not a gratuitous attack on someone else. We daily observe all these problems from the inside, and, we think, that it is our responsability to inform our end users.

We think, that it is our responsability to lead our end users toward a solution. This is why we decided to abandon the maintenance of Eventlet in a planified way, and this is why we decided to create this guide.