Supabase Outage: Platform Incident or Your Project? Codes, PGRST Errors, Detection

Failure facts checked on the vendor’s docs on Nov 8, 2026.

A Supabase project is one Postgres database with an API layer in front of it. When calls start failing, three things could be wrong: the Supabase platform, your own project, or your queries. Supabase's own docs say the second and third are the usual cause, so the status page alone will mislead you.

What the failures look like

Supabase publishes its status codes, including some it invented:

• 540: the project is paused. It cannot process requests until its owner un-pauses it.
• 544: the project API gateway timed out because the request did not finish inside the time limit.
• 546: an Edge Function was stopped for a resource limit (WORKER_RESOURCE_LIMIT).
• 402: a service restriction under the Fair Use Policy. It looks like an outage, but the cause is usage or an overdue payment.

The Data API adds PostgREST codes. PGRST000, PGRST001 and PGRST002 all return 503 when the API cannot connect to the database. PGRST003 returns 504 when a request times out waiting for a pooled connection.

Edge Functions have their own meaning for 5xx. A 500 is an uncaught exception, a 503 is a function that failed to boot and a 504 is a request that exceeded the timeout. Responses may carry an sb-error-code header naming the condition.

Platform outage or your project

Supabase states that the most common cause of HTTP timeouts and 5xx responses is under-provisioned resources, and that each project has segregated compute. A platform incident therefore leaves a different fingerprint than a hot project:

Log it per service

One log line per call is enough, with the service named so REST failures do not hide behind healthy storage traffic.

2026-11-08T09:41:07Z service=rest status=503 code=PGRST002 ms=412 project=app-prod
2026-11-08T09:41:07Z service=functions status=504 ms=150003 fn=send-receipt
2026-11-08T09:41:08Z service=auth status=200 ms=96

This is an example, not output from a real project. Capture status, the PostgREST code from the JSON body, duration and, for functions, sb-error-code.

async function sb(service: string, call: () => Promise<Response>) {
  const t0 = Date.now()
  const res = await call()
  const body =
    res.status >= 500
      ? await res
          .clone()
          .json()
          .catch(() => ({}))
      : {}
  console.log(
    JSON.stringify({
      service,
      status: res.status,
      code: body.code,
      sb_error_code: res.headers.get('sb-error-code'),
      ms: Date.now() - t0,
    })
  )
  return res
}

Thresholds worth starting with

• Page when 5xx plus timeouts exceed 5% of calls to one service for 5 minutes, with at least 20 calls in the window.
• Treat a single PGRST002 or PGRST000 burst as an incident until you rule out your own schema change.
• Track 544 count per route. A new route appearing in the list usually means a new slow query.

Reading a bad hour

Start with the shape of the failure, not the headline. A platform incident usually fails many unrelated calls at once, including cheap ones such as a primary-key lookup. A capacity problem fails the expensive calls first and spares the cheap ones. If only the heavy reporting route returns 544 while sign-ins stay healthy, the project is working and a query is not. If both fail together and project reports look calm, open the status page and filter by your product and region.

Keep one more habit: write down the first failing timestamp from your own logs before you read any status page. Vendors tend to post after the damage starts, and your timestamp is the one you can compare with their incident window later.

Getting told

Supabase moved its status page to incident.io on October 8, 2026. It supports email, RSS and Slack, lets you subscribe by product and region, and no longer supports SMS or webhook. If you subscribed through those two, resubscribe.

Checklist

• Every call is logged with service, status, code and duration.
• You can see project compute and connection reports during an incident.
• Edge Function logs are read before blaming the platform.
• Status updates reach a Slack channel or inbox someone watches.

Read vendor degradation detection for the general method and third-party failure monitoring for the family of failures. Sazabi lists Supabase integration options. Define SLOs for the calls that matter.