Turso status

How we check Turso

We watch api.turso.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.

Each Turso database answers on its own hostname behind its own token, so no single public endpoint stands in for customers generally. We watch the platform API instead, which is the path the CLI and any automation you have built use, and we pin the response an unauthenticated request gets rather than assuming a 2xx.

What is Turso?

Turso is a hosted database built on libSQL, a fork of SQLite designed for use over a network. That lineage explains what the product is for. SQLite is small, fast, and embedded, which historically meant it lived on one machine and did not travel; Turso keeps the engine and adds replication, so the same database can be placed close to the application reading it, in many locations at once.

The feature that follows from this, and the reason people choose it, is embedded replicas. Rather than every query crossing the network to a database somewhere else, the application keeps a local copy that is kept in sync, and reads are answered locally at the speed of a local file. Writes still travel to the primary. The performance difference is substantial for read-heavy workloads, and so is the failure behaviour: a period where the primary is unreachable degrades an application to read-only rather than taking it down, which is a far better outcome than most database dependencies offer.

That asymmetry is the most useful thing to understand during an incident. Reads and writes do not fail together. An application built on embedded replicas can continue serving pages, dashboards, and API responses while being unable to accept a new record, and whether users notice depends entirely on what the product does. Working that out ahead of time, and deciding what the application should say when a write cannot be accepted, is more valuable than any monitoring.

The second thing worth knowing is the split between the platform API and the databases themselves. The API serves database creation, tokens, replication settings, and everything the CLI does. Your application does not use it after setup. So a platform incident often means you cannot create a database or rotate a token while every existing database keeps answering queries normally, and that distinction is worth checking before concluding that anything user-facing is affected.

Tokens are the most common source of failures that get mistaken for outages. They are scoped, they can be issued with an expiry, and a token that has been rotated leaves behind every service that was not updated at the same moment. The resulting error appears from one service while others carry on, which is a reliable sign that the problem is a credential rather than the platform. Databases that have been renamed or moved between organisations produce a similar pattern, since the hostname the client was given is no longer the right one.

Frequently asked questions

Is Turso down right now?

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

My application cannot reach my Turso database. Where do I start?

Start with the token and the database URL, because those cause most failures. Tokens are scoped to a database or an organisation and expire if they were created with a lifetime, and a database that was renamed or moved between organisations changes the hostname your client should use. If the board above shows the platform answering normally, a credential or URL mismatch is far more likely than an outage.

Does an embedded replica keep working if Turso is unreachable?

Reads generally do, which is the main reason to use one. An embedded replica keeps a local copy of the database that your application reads from directly, so read traffic is served without a network round trip and survives a period where the primary cannot be reached. Writes still need to reach the primary, so an outage stops writes while leaving reads intact, which is a much softer failure than a total one.

Why is my first query after a quiet period slow?

Because an inactive database may need to be brought back before it answers, which shows up as one slow request followed by normal ones. This is worth knowing before treating a single slow response as an incident, particularly on a low-traffic project or a preview environment that sits idle between deploys.

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

Their page reports what Turso's team has observed and published. This page reports what our probes measured from outside their infrastructure, from five locations on a fixed schedule, whether or not an update has been posted yet. During an incident, read both.