PlanetScale status

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.

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.