# Deno status

> Is Deno down? Live status for Deno's registry and platform, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-09-01 | Canonical: https://yoping.me/status/deno

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/deno. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.