# PlanetScale status

> Is PlanetScale down? Live status, uptime history, and per-region response times for the PlanetScale API from our own probes on three continents.

Published: 2026-08-27 | Canonical: https://yoping.me/status/planetscale

## How we check PlanetScale

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

A database branch answers only to its own credentials on its own hostname, so there is no public endpoint that stands in for every customer's database. The platform API is the part that can be measured honestly from outside, and it is also the path your deploy tooling and branch automation depend on.

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/planetscale. 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 PlanetScale?

PlanetScale is a managed MySQL platform built on Vitess, the sharding
system that grew out of running MySQL at very large scale. What makes it
distinctive to work with is the branching model: a database schema is
developed on a branch, reviewed as a deploy request, and merged into
production the way code is, with the schema change applied without the
table-locking that makes conventional migrations frightening on large
tables.

That model changes which failures are likely. The traditional database
emergency, a migration that locked a table and took the site down at
three in the afternoon, mostly stops happening. What replaces it is a
sequencing problem: application code and schema are now deployed through
separate pipelines, and code that expects a column which has not been
merged yet, or which was removed in a merge that shipped first, fails in
ways that look like a database problem and are not. The fix is
discipline about ordering rather than anything the platform can do for
you.

The second thing worth understanding is the split between the platform
API and the database connection itself. The API serves the dashboard,
branch operations, deploy requests, and any automation your CI runs. Your
application does not use it; it connects to a database endpoint with its
own credentials. So a platform incident typically means you cannot open a
deploy request or look at insights, while production traffic continues
untouched. That is a good moment to stop making changes, and not usually
a moment to wake anyone up.

Credentials cause a disproportionate share of self-inflicted incidents,
because of a security decision that is correct and inconvenient. A
password is displayed once at creation and never again, so rotating one
means updating every consumer at that moment or losing the value. Teams
with several services, a CI pipeline, and a couple of scheduled jobs
reliably miss one, and the failure surfaces later, from the service
nobody remembered, usually at the least convenient time.

Connection limits are the last common surprise. Plans allow a bounded
number of concurrent connections, and serverless deployments open far
more of them than a long-running server does, since each concurrent
invocation may hold its own. The result is an application that works in
testing and starts refusing connections under real traffic, with the
database entirely healthy throughout. Routing through a pooled or HTTP
connection path is the standard answer, and it is much easier to put in
place before the traffic arrives.

## Frequently asked questions

### Is PlanetScale down right now?

Check the board above; it reflects our own probes against PlanetScale's platform API from all five of our regions, refreshed every couple of minutes. This measures the platform rather than the health of your individual database branch.

### My application cannot connect but this page shows PlanetScale up. What should I check?

Check your connection credentials and the branch they point at, since those are the usual causes. A password is shown only once when it is created, so a rotated credential that was not copied everywhere breaks exactly the services that were missed. A connection string still aimed at a branch that has since been merged and deleted produces the same symptom, as does an application that has exhausted its connection allowance.

### Does a schema change or branch merge cause downtime?

No, avoiding that is the point of the branching model. Schema changes are made on a branch and applied through a deploy request, which lets the change roll out without locking the production table the way an ordinary migration would. What can still bite is application code deployed before or after the schema it expects, which is a sequencing problem on your side rather than a platform outage.

### Why are my queries slower than they were last week?

Most often because of your own data and query patterns rather than the platform. A query that no longer uses an index as a table grows, a hot row causing contention, or a workload that crossed a scaling threshold will all slow things down with nothing wrong at PlanetScale. The insights view reports the slowest and most frequent queries, which is where this is diagnosed.

### How is this page different from PlanetScale's own status page?

Their page reports what PlanetScale's engineers have confirmed and published, broken down by component. This page reports what our probes measured from outside their infrastructure, on a fixed schedule, whether or not an update has been written yet. Ours is the earlier and coarser signal, theirs is the authoritative one.