Does Supabase have an SLA? The 99.9% Enterprise uptime commitment, its credit tiers, and how to claim

Supabase sits underneath a lot of production apps now — the database, the auth, the storage and the edge functions all at once. So when it has a bad hour, the first question a FinOps or platform lead asks is a simple one: *do they owe us anything?* The answer depends almost entirely on one word in your contract.

Does Supabase have an SLA with service credits?

Yes — but only for Enterprise customers. Supabase's published Service Level Agreement applies to "Enterprise Customers specified in an Order Form". For them, Supabase commits to 99.9% Actual Availability in each calendar month, with each product individually covered. If it misses, the customer can request a service credit of 10%, 15%, 20% or 30% of the monthly fees for the affected service, depending on how far availability fell. The request goes by email to support@supabase.io within 30 days of the end of the month, and total credits are capped at 20% of the fees paid for the affected services over the preceding 12 months.

If you are on the Free, Pro or Team plan, the uptime SLA does not cover you. (Team customers get Supabase's *support* response-time SLA, which is a different thing and carries no credit.)

What does the Supabase uptime commitment actually promise?

Source: Supabase's published Service Level Agreement, read on 2 October 2026; Ontracko's Supabase SLA profile carries the same tariff.

How much downtime does 99.9% allow?

Supabase defines Actual Availability as Scheduled Availability minus Unscheduled Downtime, both in minutes. In a 30-day month (43,200 minutes), 99.9% leaves about 43 minutes of Unscheduled Downtime before the commitment is missed. The tier boundaries fall at:

For the general arithmetic behind these figures, see what a 99.9% SLA actually allows.

What counts as Supabase downtime?

This is where Supabase's SLA is more specific than most. Each product has its own downtime definition and its own SLA scope, and the scope decides whether an incident counts at all:

• Project scope — Postgres, Auth, Data APIs (PostgREST). The SLA applies to each project individually. For Postgres, downtime is any period the managed database for a project "is not generally accessible" for reads or writes.
• Regional scope — Storage, Pooler (PgBouncer & Supavisor), Management API, Branching, Realtime, Functions. The SLA is breached only if more than 1% of projects in a single region are affected.
• Global scope — Studio, Logging. Breached only if more than 1% of projects worldwide are affected.

The practical consequence: a Storage or Functions problem that hits *your* project but not 1% of the region may be real downtime for you and still not a breach. A Postgres outage on your project is assessed against your project alone.

Products also have dependencies. Auth depends on Postgres; Data APIs depend on Postgres and Auth; Storage depends on Postgres and Pooler. Each dependent product excludes "unavailability caused by upstream service outages listed in Dependencies" — so a Postgres outage that takes Auth down with it is a Postgres claim, not two.

What does the Supabase SLA exclude?

The general exclusions are broad, and two of them catch people out:

1. Third-party vendors and cloud providers — the SLA names AWS, Cloudflare, GCP, Azure and GitHub, among others. If the root cause is upstream of Supabase, the minutes do not count.
2. Customer configuration and capacity — insufficient CPU, memory, storage or I/O for your workload, misconfigured pooler settings, unsupported or outdated Postgres versions and extensions, and customer-initiated schema changes are all excluded.

Also excluded: force majeure and ISP outages, integration partners (the SLA gives Resend for email as an example), Beta and Alpha products, and announced Scheduled Downtime/Maintenance Windows.

How to claim a Supabase SLA credit

1. Confirm you are covered: your Supabase subscription must be Enterprise, under an Order Form, and the affected product must be GA (not Beta or Alpha).
2. Identify the product and its scope. For Project-scoped products, your project's downtime is what matters; for Regional or Global products, check that the incident affected more than 1% of projects in the region or worldwide — the Supabase status page is the public record.
3. Rule out the exclusions: an upstream provider incident, a dependency outage, or your own capacity or configuration.
4. Build the timeline in 5-minute intervals — the SLA requires "the specific dates and times (in 5-minute intervals) during which the service was unavailable".
5. Attach supporting logs or monitoring data showing failed requests or clear unavailability. Supabase reserves the right to validate the claim against its own internal monitoring and may deny claims inconsistent with it, so your own evidence carries the weight.
6. Email support@supabase.io with the affected organization, service(s), region(s) and project(s), the 5-minute-interval timeline and the evidence, within 30 days of the end of the affected month.
7. Check the credit lands: if Supabase confirms eligibility, it issues the credit to your account within 30 days, applied to future billing charges.

A worked example

Say your Enterprise Order Form puts Postgres at $3,000 a month, and in a 30-day month your project's database was not accessible for a cumulative 9 hours (540 minutes) of qualifying, non-excluded downtime. Actual Availability is (43,200 − 540) ÷ 43,200 ≈ 98.75% — below 99.0%, at or above 98.0% — so the tier is 15%, and the credit is 15% × $3,000 = $450. That is well inside the cap unless you have already drawn heavily on credits for Postgres over the past year: the cap is 20% of the fees for the affected service across the preceding 12 months, and anything above it is forfeited.

The credit calculator on the Supabase SLA page runs the same tiers against your own spend.

Frequently asked questions

Does Supabase have an uptime SLA on the Pro or Team plan?

No. Supabase's published uptime SLA applies only to Enterprise customers specified in an Order Form. Team customers receive a support response-time SLA, which sets how quickly Supabase responds to tickets but carries no availability commitment and no service credit.

What is Supabase's uptime guarantee?

For Enterprise customers, 99.9% Actual Availability in each calendar month, with each product individually covered and availability measured by Supabase. That leaves about 43 minutes of unscheduled downtime in a 30-day month.

How much is a Supabase SLA credit?

10% of the affected service's monthly fees below 99.9%, 15% below 99.0%, 20% below 98.0% and 30% below 96.0%. Total credits are capped at 20% of the fees paid for the affected services over the preceding 12 months.

How long do I have to claim a Supabase credit?

Thirty days from the end of the calendar month in which the uptime commitment was missed. The request goes by email to support@supabase.io.

Am I owed a credit if Supabase was down for two hours?

On an Enterprise plan, two hours of qualifying downtime in a 30-day month is about 99.72% availability — below 99.9%, so the 10% tier — provided the product's scope test is met and no exclusion applies. On Free, Pro or Team, no credit is owed under the published SLA.

Does Supabase refund money for outages?

No. Service credits are applied to future billing charges; they are not refunds and cannot be exchanged for cash. They are also the sole and exclusive remedy for missing the uptime commitment.

Is a Supabase outage caused by AWS covered?

No. The SLA excludes issues attributable to external vendors or cloud providers and names AWS among them. If an upstream provider caused the downtime, those minutes do not count toward a breach.

Methodology & caveats

Every term above — the Enterprise-only scope, the 99.9% calendar-month commitment, the per-product downtime definitions and Project/Regional/Global scopes, the dependency and general exclusions, the 10/15/20/30% tiers, the support@supabase.io claim route, the 30-day deadline, the 5-minute-interval and evidence requirements, and the 20%-of-12-months cap — is transcribed from Supabase's published Service Level Agreement as read on 2 October 2026. Downtime minutes are our arithmetic on a 30-day month. Your Order Form may vary these terms; where it does, it controls. Ontracko scores status-page incident duration, which is evidence a qualifying event occurred, not the availability figure Supabase computes — which is exactly why the SLA asks you for your own logs. For context across vendors, see which SaaS vendors actually pay SLA credits, SLA claim deadlines by vendor, the reliability rankings and the SLA glossary.

*A Supabase claim lives or dies on a 5-minute-interval timeline you kept yourself — Supabase checks it against its own monitoring. Ontracko watches the Supabase status feed for free, times every incident, and flags when a month crosses 99.9% so the 30-day window doesn't close on you. Monitor Supabase free — 8% only on recovered credits. See Supabase live status or open the Supabase SLA page.*