Xata status

How we check Xata

We watch xata.io 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.

A Xata database answers on a per-workspace hostname behind an API key, so there is no shared public endpoint that would represent customers generally. We watch Xata's own platform host, which is an honest signal about the company's infrastructure and explicitly not a claim about your individual database.

What is Xata?

Xata is a serverless database platform built on Postgres, with search, analytics, and file attachments layered on top and a type-safe client generated from the schema. The pitch is that a team gets a relational database without operating one, plus the things applications usually bolt on afterwards, without running a separate search cluster or object store alongside it.

The layering is the first thing to understand when something looks wrong. A record written to the database becomes searchable through a separate index, and that index is updated asynchronously. The window is short, but it exists, and it is enough to break a flow that writes a record and then immediately reads it back through search. The record is not missing and nothing has failed; the application asked the wrong system a moment too early. This is the single most common Xata surprise, and it is a design property rather than an incident.

Branching is the second concept that shapes how failures appear. Xata supports database branches in the way version control does, so schema changes can be developed and reviewed separately from production. That is useful, and it introduces a class of configuration error where a client is pointed at a branch that no longer exists, or at the wrong one after a merge. The error says the resource was not found, which reads like data loss to whoever sees it first, and is not.

The platform and the databases fail separately, as with any managed service. The console, the workspace API, and the schema tooling can be degraded while queries from your application continue to be answered, and the reverse is possible too. Checking which of the two is actually affected is worth doing before concluding that anything user-facing is broken.

Finally, a note about where a hosted database sits in your architecture. Because Xata is reached over HTTP with an API key rather than through a long-lived connection, it fits serverless deployments comfortably and avoids the connection-exhaustion problem that catches teams running Postgres directly behind functions. The trade is an ordinary network dependency in the request path, with the ordinary consequences: latency that varies with distance, and a hard requirement to handle timeouts in code rather than assuming the database is always a millisecond away.

Frequently asked questions

Is Xata down right now?

Check the board above; it reflects our own probes against Xata's platform from all five of our regions, refreshed every couple of minutes. Your workspace has its own hostname and region, so treat this as a platform signal rather than a reading of your database.

My queries are failing but this page shows Xata up. What should I check?

Check your API key and the branch your client is pointing at, since both are common causes. A key that was revoked or belongs to a different workspace produces an authentication failure, and a client configured against a branch that has since been deleted or renamed produces a not-found error. Neither is an outage and neither would appear on any status page.

Does a Xata incident affect search as well as the database?

Not necessarily. Xata layers search and analytics on top of the database, and those indexes are maintained separately from the primary records. It is possible for writes to succeed while a search index lags behind, which looks like missing data to an application that reads through search immediately after writing.

Why does a record I just wrote not appear in search results?

Because search indexing is asynchronous, so there is a short window where a record exists in the database but is not yet searchable. This is normal behaviour rather than a fault, and it matters for any flow that writes a record and then immediately reads it back through a search query. Reading through the database directly is the reliable path when you need the record straight away.

How is this page different from Xata's own status page?

Theirs reports what Xata's team has confirmed from inside the platform. This page reports what our probes measured from outside it, on a fixed schedule, whether or not an update has been posted. Ours arrives earlier and says less; theirs is the authoritative account.