# Turso status

> Is Turso down? Live status, uptime history, and per-region response times for Turso's platform, measured by our own probes rather than user reports.

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

## 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.

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/turso. 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 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.