# Neon status

> Is Neon down? Live status, uptime history, and per-region response times for Neon Postgres, measured since August 2026.

Published: 2026-08-25 | Canonical: https://yoping.me/status/neon

## How we check Neon

We watch console.neon.tech 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 console rather than a raw Postgres connection, since a database wire-protocol check needs a real database and credentials to mean anything, while the console's own reachability is a real, honest signal of the control plane's health that does not require holding a customer's connection string.

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/neon. 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 Neon?

Neon is a managed Postgres platform built around separating storage from
compute, which lets it do things a traditional single-server Postgres
setup cannot: branch a database the way you branch code, scale compute
up and down independently of the data it holds, and suspend an idle
database entirely rather than paying to keep it running when nothing is
using it. For a team that wants real Postgres without running and tuning
the server themselves, that combination has made it a common choice for
new projects.

The architecture changes what "down" even means in a way worth
understanding before assuming an incident. A Neon database that has
scaled to zero because nothing queried it recently is not down, it is
suspended, and the next connection wakes it up with a short, normal delay
that is easy to mistake for a problem if you do not know it is coming.
A genuine platform incident looks different: a wake attempt that never
completes, a query that fails outright rather than just arriving a moment
late, or a control-plane console that is itself unreachable.

That branching model also means an incident can be scoped in a way a
traditional database host's incidents are not. A specific branch, a
particular compute endpoint, or one region's infrastructure can degrade
independently of everything else on the platform, which is different from
a traditional single-server host where one problem tends to mean the
whole instance is affected.

Because the actual database connection itself needs real credentials to
test meaningfully, this page watches Neon's console, the control plane
every project's dashboard and connection management goes through, as an
honest proxy for whether the platform as a whole is healthy. If your own
application cannot reach its database and the board above shows Neon
healthy, check your connection string, your connection pool limits, and
whether the delay you are seeing is simply the normal wake-from-idle cold
start before assuming a platform incident.

## Frequently asked questions

### Is Neon down right now?

Check the board above; it reflects our own probes against Neon's console, refreshed every couple of minutes from all five of our regions.

### My application cannot connect to its Neon database. Is that a Neon outage?

Not necessarily. An expired connection string, a database that scaled to zero and is still waking up, or a connection pool exhausted on your own application server produces a symptom that looks identical to a real platform incident. If the board above shows Neon healthy, check your own connection configuration and pool settings first.

### What does scale-to-zero mean for how an outage looks?

Neon can suspend an idle database and wake it on the next connection, which introduces a brief, normal delay that is easy to mistake for downtime if you are not expecting it. A genuine outage is a database that fails to wake up or stays unreachable well past that normal cold-start window, not a single slow first query.

### How is this different from Neon's own status page?

Theirs reflects incidents their own team has confirmed and posted. Ours reflects what we measure independently from outside their infrastructure, on a fixed schedule regardless of whether an official update has gone up yet.