# Upstash status

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

Published: 2026-08-29 | Canonical: https://yoping.me/status/upstash

## How we check Upstash

We watch upstash.com 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.

Every Upstash database answers on its own per-database hostname behind its own token, so there is no shared public endpoint that represents customers generally. We watch Upstash's own platform host, which is an honest signal about the company's infrastructure and deliberately not a claim about your individual database.

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/upstash. 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 Upstash?

Upstash provides serverless data stores, primarily Redis and Kafka,
billed per request rather than per hour. That pricing model is the whole
point. A conventional Redis instance is a server you rent continuously
whether or not anything is using it, which is a poor fit for an
application that runs as functions and may be idle most of the day.
Upstash bills for what is actually used, which makes a cache economically
sensible for workloads that could never justify a dedicated instance.

The architectural consequence is the HTTP API, and it is the detail worth
understanding before something goes wrong. Redis normally speaks its own
protocol over a long-lived TCP connection, which assumes a process that
starts, connects, and stays alive. Serverless functions do not work that
way: they start, handle a request, and may vanish, and if each invocation
opens a Redis connection the connection count climbs with traffic until
the database refuses new ones. Upstash's HTTP API removes that problem by
making every command a stateless request, which is why it is the right
default in a function and why an application that ignores it will look
fine in testing and fall over under load.

Geography is the second thing to plan for. A database is created in a
region, and requests from other regions pay the round trip. It is common
to see a serverless application deployed across several regions talking
to a single database in one of them, where the function is fast, the
network is not, and the resulting latency looks like a service problem.
Global databases with read replicas address this directly, but only if
the deployment was designed with the question in mind.

Usage limits are the most frequent cause of errors that get mistaken for
outages. Plans cap daily commands, request sizes, and bandwidth, and
crossing a limit produces failures from a perfectly healthy service. The
pattern is distinctive once you know it: everything works, then errors
begin at a consistent time of day, then everything works again after the
counter resets. That is not an incident, and no status page will
acknowledge it.

The last point concerns what a cache outage should do to your
application. A cache that is unreachable ought to degrade gracefully, the
request falling through to the underlying database and taking longer,
rather than failing outright. A surprising number of applications treat a
cache miss and a cache error identically in the happy path and quite
differently in the error path, and discover during an incident that a
component chosen to make things faster has become one that can make
everything stop.

## Frequently asked questions

### Is Upstash down right now?

Check the board above; it reflects our own probes against Upstash's platform from all five of our regions, refreshed every couple of minutes. Your own database lives on its own hostname in its own region, so this is a platform signal rather than a per-database one.

### My Upstash database is returning errors but this page shows Upstash up. What should I check?

Check your usage limits and your token first, because those are the common causes. Upstash bills per request with plan limits on daily commands, request size, and bandwidth, and hitting one produces errors from a service that is otherwise entirely healthy. A rotated token, or a request sent to a database in a different region than the token belongs to, produces the same kind of failure.

### Why is my Redis latency higher from one part of the world?

Because a database is created in a specific region unless it is a global one, and every request from elsewhere pays the round trip. This surprises people running serverless functions in multiple regions against a single database, since the function is fast and the network is not. Global databases with read replicas exist to solve exactly this, and the per-region readings above show the same effect on our own probes.

### Does the HTTP API behave differently from the Redis protocol connection?

Yes, and the difference matters in serverless environments. The HTTP API is stateless, so each request stands alone and nothing has to be kept open between invocations, which is why it suits functions that may run once and disappear. A conventional Redis connection expects to be long-lived, and code that opens one per invocation will exhaust connections under load in a way the HTTP path does not.

### Is my data still there after an incident?

Yes, durability and availability are separate concerns and an incident affects reachability rather than the contents of your database. What is worth checking after any incident is whether your application wrote through a cache-aside path that silently skipped writes while the database was unreachable, since that is a data consistency problem your own code creates rather than one the platform does.