CockroachDB status

How we check CockroachDB

We watch cockroachlabs.cloud 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 managed cloud platform host rather than a cluster endpoint, because a customer cluster answers only to its own certificates and allowed networks and cannot be probed honestly from outside. This measures whether Cockroach Labs' cloud service is reachable, which is a narrower claim than whether any particular cluster is healthy, and we would rather state the narrow thing accurately.

What is CockroachDB?

CockroachDB is a distributed SQL database that keeps a familiar Postgres interface while replicating data across nodes and, if you want, across regions. The design goal is survivability: individual nodes, availability zones, or whole regions can fail without the database becoming unavailable, because every range of data is replicated and writes commit once a majority of replicas agree. The trade is that this consensus has a cost, and understanding where that cost lands explains most of what people find surprising about running it.

The cost is latency on writes. A write is not durable until a majority of replicas have acknowledged it, so the distance between replicas sets a floor on how fast a write can possibly commit. Within one region that floor is small enough to ignore. Spread across continents it is not, and a multi-region cluster set up without thinking about data placement will show write latencies that look like a performance regression and are actually physics. Locality settings exist to pin data close to the users who write it, and they are the difference between a multi-region deployment that feels fast and one that feels broken.

The second thing that catches teams new to the database is transaction retries. CockroachDB provides serializable isolation, the strongest level, which means it will refuse to commit a transaction that would produce an anomaly and asks the client to try again. Applications ported from a database running at a weaker default see retry errors they have never encountered and read them as instability. They are the opposite: the database is declining to silently corrupt your invariants. What they do indicate is contention, usually several transactions competing for the same row, which is an application design question rather than an availability one.

The managed cloud service adds the same control plane and data plane split that every hosted database has. The console and the cluster API can be degraded while your cluster serves traffic normally, which means you cannot scale, inspect, or reconfigure anything, and your users notice nothing. It is worth resisting the urge to intervene during such a window, because the tools you would intervene with are the ones that are unavailable.

Finally, the resilience story only works if the deployment was built to use it. A cluster running in a single availability zone survives node failures and nothing larger. The database can tolerate a region loss, but only if it was configured across regions in the first place, and that is a decision made long before the incident that would have justified it.

Frequently asked questions

Is CockroachDB Cloud down right now?

Check the board above; it reflects our own probes against the CockroachDB Cloud platform from all five of our regions, refreshed every couple of minutes. It measures the managed platform, not a self-hosted cluster you run yourself.

Does a single node failing mean my database is down?

No, and surviving that is the reason to run CockroachDB in the first place. Data is replicated across nodes and the cluster keeps serving as long as a majority of replicas for each range remain available, so losing a node produces a brief rebalance rather than an outage. What you may notice is a latency increase while ranges are re-replicated, which is very different from unavailability.

Why are my transactions failing with retry errors?

Because CockroachDB uses serializable isolation, and retry errors are the expected way it tells you two transactions conflicted. They are not a sign of an outage, they are the database refusing to give you an anomaly that a weaker isolation level would have hidden. Client libraries are meant to catch and retry them, and an application seeing them frequently usually has contention on a hot row rather than a platform problem.

My queries got slower after adding a region. Is that expected?

Often yes, and it is a consequence of how consensus works rather than a fault. A write must reach a majority of replicas before it commits, so replicas placed further apart mean a longer round trip on every write. Table locality settings exist precisely to control this, and a multi-region cluster configured without them will pay the wide-area latency on writes that did not need it.

Does this page cover self-hosted CockroachDB?

No. This page watches Cockroach Labs' managed cloud platform. A cluster you run on your own infrastructure has entirely separate availability, and its health depends on your machines, network, and operations rather than anything measured here.