Deno status

How we check Deno

We watch deno.land from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the module host that Deno programs resolve their imports against, because in this runtime a dependency is a URL and an unreachable host is a program that will not start rather than a package manager that cannot install. Deno Deploy and the newer registry are separate services with their own availability.

What is Deno?

Deno is a JavaScript and TypeScript runtime built around a design choice that changes how outages feel: dependencies are URLs. Rather than installing packages into a directory and importing from there, a Deno program imports directly from a host, and the runtime fetches and caches what it needs. It removes an entire layer of tooling, and it moves the dependency on remote infrastructure from install time to start time.

That relocation is the most important thing to understand here. In an ecosystem with a package manager, a registry outage stops you installing and leaves running applications alone. In Deno's original model, a program that has not cached its imports needs those hosts to be reachable in order to start at all. A container built fresh, a new deployment, or a cold start on a machine without the cache can be blocked by a host that has nothing to do with your code, and the failure appears as a program that will not boot rather than as an install error.

The caching layer is what makes this workable, and using it deliberately is the difference between resilient and fragile. Deno caches remote modules after fetching them once, a lockfile pins their integrity, and vendoring copies them into the project. A deployment built with those in place does not need any remote host at startup. Teams that skip them are depending, at every cold start, on the availability of every host in their import graph, including third-party ones nobody audited.

That import graph is the second complication. Modules are commonly served from several places, including Deno's own registry, general-purpose CDNs, and git forges, and a program's dependencies can span all of them. An outage at any single one produces the same startup failure, so the useful diagnostic step is reading which URL actually failed rather than checking one status page and drawing a conclusion. This page watches Deno's own module host, which is one host among the several a real program may touch.

Deno Deploy, the company's hosting product, is a separate service with its own infrastructure and its own components on the official status page. An application already running there has its dependencies resolved and does not re-fetch them per request, so a registry problem shows up as an inability to deploy something new rather than as a failure of what is already live.

Frequently asked questions

Is Deno down right now?

Check the board above; it reflects our own probes against Deno's module host from all five of our regions, refreshed every couple of minutes. Deno Deploy, the hosting product, is a separate service that this reading does not cover.

My Deno program will not start because a module cannot be fetched. Is that an outage?

It can be, and it is the failure mode most specific to Deno. Because imports are URLs resolved at startup, a host that is unreachable stops the program rather than a package installation. Check whether the failing import points at Deno's own registry or at a third-party host such as a CDN or a git forge, since an outage at any of them produces the same error.

How do I keep a Deno application running when a module host is down?

Use a lockfile and vendor or cache your dependencies, which removes the network from startup entirely. Deno caches remote modules locally after the first fetch, and committing a lockfile plus vendored dependencies means a deployment does not need any external host to be reachable in order to start. Doing this before an incident is the only time it can be done.

Does an outage here affect Deno Deploy applications?

Not necessarily. Deno Deploy runs applications on its own edge infrastructure, and an already-deployed application with its dependencies cached does not re-fetch them from the registry on every request. What a registry outage does reliably break is a new deployment that needs to fetch modules it has not seen before.

Is this page about the Deno runtime or the hosted platform?

It watches Deno's module host, which is the piece that programs depend on at startup. The runtime itself runs on your machine and cannot go down in any meaningful sense, and Deno Deploy is a separate hosted product with its own components on Deno's official status page.