Upstash status

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.

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.