Skip to main content

Is PlanetScale Down?

No — PlanetScale is up

Reachable from all 8 checked regions

Average response time: 431ms

Last checked · checks run every 6 hours

Official status page: https://www.planetscalestatus.com

PlanetScale uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
470ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 10 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

10-day clean streak
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: no data
Aug 6: no data
Aug 7: no data
Aug 8: no data
Aug 9: no data
Aug 10: no data
Aug 11: no data
Aug 12: no data
Aug 13: no data
Aug 14: 100.00% uptime, 16 checks
Aug 15: 100.00% uptime, 32 checks
Aug 16: 100.00% uptime, 31 checks
Aug 17: 100.00% uptime, 40 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 40 checks
Aug 20: 100.00% uptime, 32 checks
Aug 21: 100.00% uptime, 39 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 24 checks
Jul 25 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
443ms
DNS 131ms TCP 113ms TLS 94ms TTFB 443ms
arn
386ms
DNS 63ms TCP 104ms TLS 105ms TTFB 385ms
nrt
608ms
DNS 112ms TCP 161ms TLS 163ms TTFB 608ms
ord
132ms
DNS 45ms TCP 22ms TLS 29ms TTFB 132ms
sin
868ms
DNS 180ms TCP 225ms TLS 226ms TTFB 867ms
sjc
269ms
DNS 54ms TCP 67ms TLS 68ms TTFB 269ms
syd
674ms
DNS 56ms TCP 203ms TLS 202ms TTFB 673ms
yyz
74ms
DNS 4ms TCP 18ms TLS 19ms TTFB 74ms

What PlanetScale does

PlanetScale is a managed database platform offering MySQL built on Vitess and, more recently, Postgres, on both AWS and Google Cloud. Applications connect to it as their primary datastore, so it sits directly in the request path. Its status page separates connectivity from database operations and dashboard access, because the data path and the control plane fail independently.

What an outage looks like

Applications report connection timeouts or refused connections, and connection pools fill with failing handles. Queries that do open run slowly or error mid-transaction. Schema changes and branch operations stall in the dashboard. Query Insights stops recording while the database itself still serves traffic, which is a control-plane fault rather than an outage of the data path.

What to do about it

Check planetscalestatus.com, which reports connectivity separately for Vitess and Postgres and separately per cloud, so confirm the engine and provider your database runs on rather than reading the overall heading. A dashboard or API failure does not imply your application is affected. Connection pooling and retry with backoff absorb short connectivity incidents without a user-visible failure.

Is it down for everyone, or just you?

If this page says PlanetScale is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

PlanetScale outage FAQ

Is my application down if the PlanetScale dashboard is?
Not necessarily. The dashboard and API are a separate component from database connectivity, so the control plane can fail while every application connection keeps working, and the reverse also happens. Read the component matching your engine and cloud provider rather than the page heading, since PlanetScale reports Vitess and Postgres on AWS and GCP as four distinct entries.
Will an outage lose committed data?
A committed transaction is durable, so an outage does not undo work the database acknowledged. What is at risk is work in flight: transactions open when connectivity dropped roll back rather than commit. Applications that treat a failed write as done, instead of retrying it or surfacing the error, are the usual source of data missing after an incident.
Do schema changes stall during an incident?
Schema changes run through database operations, which the status page tracks separately from connectivity, so a change can sit unapplied while the database serves queries normally. Leaving it queued is generally safer than cancelling part way through, and the database operations component tells you whether the delay is the platform or your own change waiting on something.
Which cloud region should I be watching?
The one the database was created in. PlanetScale reports connectivity per engine and per cloud provider, so an AWS incident can leave GCP-hosted databases untouched. Teams running their database and their application at different providers see the two fail independently, which is worth knowing before blaming the application during a connectivity incident.

How we measure this

  • We request PlanetScale's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where PlanetScale publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when PlanetScale goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required