Skip to main content

March 2 incident update

On Tuesday at 02:01 AM UTC several services provided by the Deno organization had a 98 minute service disruption. This impacted images and videos on the website, serving of TypeScript files on and, generation of documentation reports on, and downloading of registry metadata from We have concluded that this outage was the result of a rouge abuse prevention filter at an upstream service provider, Cloudflare. This post details what exactly happened, how we recovered the systems, and what we are doing to prevent this in the future.

All services are now operating normally again. The registry API at was not impacted by this incident. No data was lost. We take outages like these seriously and sincerely apologize for the disruption.

To understand what actually happened it is important to know that we released Deno 1.8 and published the release notes in a blog post 1.5 hours before the incident. This blog post ended up on Hacker News about 30 minutes before the incident. At the time of incident we were receiving about 9x the regular traffic to the site.

Timeline of events

At 02:00 AM UTC we received an email from an automated system at Cloudflare notifying us that all media on had been blocked due to a suspected violation of section 2.8 or their TOS. This section of the TOS details that Cloudflare may not be used to serve primarially media files. Upon receival of this email we decided to remove the screen captures and images from the 1.8 blog post as a temporary mitigation. This was done at 02:09 AM UTC. This did not resolve the issue. At 02:22 AM UTC we opened a support ticket with Cloudflare.

At 03:00 AM UTC we decided we would move our infrastructure to an alternative infrastructure provider ( to mitigate the outage. Huge thanks to Kurt Mackey from for helping with this effort and providing us with infrastructure right away. We switched over the DNS records for the affected services at 03:24 AM UTC. This resolved the outage for the majority of users worldwide at 03:41 AM UTC.

Cloudflare resolved the block they had put on our site at 18:40 PM UTC - 16.5 hours after the incident started, and 16 hours after we reached out. This was the first non-standardized response we got from them after opening the ticket.

Root cause

Our initial analysis of the incident concluded that Cloudflare had blocked all media files for the zone - likely due to the steep increase of traffic due to Hacker News. This alone should have not taken down or as these do not serve media, but source code. This was caused by Cloudflare seemingly interpreting all .ts files, regardless of content or content-type header, as MPEG transport streams (which fall under the media block). In our case this was not correct because .ts files can be both MPEG transport streams, or TypeScript files (as is the case for us). All of our typescript files are served with application/typescript.


As you might know, Deno imports remote code using URLs. This means that if the host of the module you want to import experiences an outage, you will not be able to download this module from that host anymore. This is the same problem all package managers have - for example when experiences an outage, you can not npm install anymore.

Does this mean that you are not able to run your project when the module host goes down? No. Deno caches all remote imports in a global cache directory on your system. This means that when you import the a bit of code for the first time it will be downloaded and cached, and then on subsequent runs you will be able to use that code offline without needing network access - just like with node_modules.

We expect the impact of this outage to be relatively minimal to most developers who use Deno on active projects, as they would have likely had their dependencies cached already. This outage overwhelmingly impacted new Deno users, and CI pipelines.

It is also important to note that the Deno CLI does not depend on the domain to be online to function. It is completely registry agnostic. If your project is only made up of modules from other registries, like,,, or, you would have seen no impact from this outage.

What’s next?

Cloudflare reached out to us Tuesday evening to discuss what happened. After an initital investigation they concluded that this was an error in their abuse monitoring system. Cloudflare has assured us this issue will not occur again, and that they will implement changes in their systems to make sure this will not happen to any other Cloudflare customers.

Cloudflare has also assured us that a 16 hour gap between false detection and remediation is not acceptable, and that this will be an area of immediate focus for them.

This experience has solidified our belief that building the Deno runtime on standardized, open web APIs like fetch was the right move. Because Cloudflare Workers builds on these standard web APIs too, we were able to migrate our primary Cloudflare Worker to a Deno script running on in under 20 minutes. We only had to polyfill the “fetch” event to get our workers running.

If you are interested, this is the code we used to polyfill the “fetch” event: Try run this example locally, then visit

$ deno run --allow-net
Listening on

As a result of this incident we have set up a public status page. This page shows the current status of,,, and You can view it at