How to claim a Snowflake SLA credit (and why it isn't money)
Snowflake's SLA pays you in Snowflake credits, not dollars — 1x, 3x or 7x your Average Daily Snowflake Credits, applied to next month's usage in the affected region. Here's the credit table, the 21-day deadline that runs from month-end, and how to file.
Most SLA credits are a percentage of the money you paid. Snowflake's is not. Its remedy is denominated in Snowflake credits — the consumption unit you already buy compute with — and the agreement says in as many words that those credits cannot be converted to cash. That single design choice changes how you value a Snowflake claim, and it is why teams who go looking for "how much money do I get back" find nothing that adds up.
The short answer
If the Snowflake Service misses its availability commitment in a calendar month, your sole and exclusive remedy is a Service Level Credit worth 1x, 3x or 7x your Average Daily Snowflake Credits, depending on how far availability fell. The credit is non-cash — it is applied against your usage in the affected Cloud Provider Region in the immediately succeeding calendar month, and may not be exchanged for or converted to a monetary amount. You must request it within 21 days of the calendar month in which the failure occurred, and Snowflake does not pay it automatically. Nothing about the claim depends on your dollar spend, so the number to know is your average daily credit consumption, not your invoice total.
What Snowflake actually commits to
Snowflake measures availability by query error rate, not by wall-clock "site is down" minutes — the service is treated as unavailable when the error rate exceeds the threshold over a measurement interval. Since June 2022 the commitment has had two thresholds running side by side, and Snowflake applies whichever is more demanding:
| Threshold | Availability commitment | Error-rate trigger |
|---|---|---|
| Stricter error bar | 99.9% per calendar month | more than 1% of queries erroring |
| Stricter uptime bar | 99.99% per calendar month | more than 10% of queries erroring |
The second line is the one worth reading twice. A short, severe event — a few minutes where most queries fail — can breach the 99.99%/10% threshold even though it never comes close to burning the ~43 minutes a plain 99.9% SLA allows. Snowflake introduced the dual structure specifically to cover short high-error outages, and said at the time that doing so increased the number of credits it issues by roughly a quarter. If you have only ever checked your month against 99.9%, you have been under-counting your own breaches.
Because the metric is error rate rather than uptime minutes, a Snowflake month can breach without anything on the status page looking like an outage. That distinction is worth understanding generally — see how SLA uptime is actually measured and what a 99.9% SLA actually allows.
What you're owed
| Monthly availability | Service Level Credit |
|---|---|
| Below the applicable commitment, but 99.0% or above | 1x Average Daily Snowflake Credits |
| Below 99.0%, but 95.0% or above | 3x Average Daily Snowflake Credits |
| Below 95.0% | 7x Average Daily Snowflake Credits |
"Average Daily Snowflake Credits" is exactly what it sounds like: your average daily consumption of Snowflake credits. So the entry tier returns roughly one average day of compute, the middle tier three days, and the worst tier a week.
That is a useful sanity check against percentage-based SLAs. One average day out of a ~30-day month is on the order of 3% of your monthly compute consumption — arithmetic on the definition, not a figure Snowflake publishes. It sits in the same range as the 10%-of-fee entry tier you see elsewhere once you account for the fact that Snowflake's unit is consumption rather than the whole invoice. It is a real remedy; it is not a windfall, and it will not cover the business cost of the outage.
Two consequences follow from the unit:
- Storage and other non-credit charges are untouched. The remedy reduces future consumption. It does not reduce a bill you have already paid.
- A credit is worth little if you don't consume next month. It lands against usage in the succeeding calendar month, in the region that was affected. A workload you have since migrated to another region does not absorb it.
The deadline runs from month-end, not from the incident
This is the part that quietly kills Snowflake claims. The window is 21 days of the calendar month in which the Service Level Failure occurred — so the clock is anchored to the month, not to the incident. An outage on the 2nd and an outage on the 27th share the same deadline. Practically, that means:
- An event early in the month gives you seven-odd weeks of notice, and everyone forgets.
- An event in the last days of the month leaves you roughly three weeks, part of which is spent waiting for the month to close so the availability figure is even final.
Twenty-one days is short by market standards — most SaaS vendors allow 30, and AWS and Azure allow 60. Only Cloudflare's five business days and Atlassian's 15 days are tighter among the vendors we monitor. The full comparison is in SLA credit claim deadlines by vendor.
How to claim a Snowflake SLA credit
- Confirm the failure month. Availability is assessed per calendar month per Cloud Provider Region, so establish which month and which region you are claiming for before anything else. Snowflake's incident history is on its status page.
- Establish your error rate, not your downtime. Because the commitment is written against query error rate, the evidence that matters is failed-query volume over the affected interval — pull it from your own query history for the account in that region.
- Compute your Average Daily Snowflake Credits for the relevant period, and identify which band the month falls into (1x / 3x / 7x).
- Open a support case with Snowflake requesting Service Level Credits, naming the affected Cloud Provider Region and the affected month, and attaching your error-rate evidence.
- File within 21 days of the end of the failure month — the request must be made inside that window, and no credit is issued unless you ask for it.
- Check next month's usage statement for the credit applied against consumption in that region.
Frequently asked questions
Does Snowflake refund you for downtime?
No — not in cash. Snowflake's SLA remedy is a Service Level Credit denominated in Snowflake credits, applied against your usage in the following calendar month. The agreement states these credits may not be exchanged for or converted to monetary amounts. It is your sole and exclusive remedy for the failure.
What is Snowflake's uptime SLA?
Snowflake commits to availability measured by query error rate against two thresholds applied together: 99.9% per calendar month at a 1% error rate, and 99.99% per calendar month at a 10% error rate. The more demanding of the two governs, which is what lets short, high-error outages qualify.
How long do I have to claim a Snowflake SLA credit?
Twenty-one days of the calendar month in which the failure occurred. The deadline is anchored to the month rather than to the incident date, so an outage late in the month leaves you materially less time than one early in the month.
How much is a Snowflake SLA credit worth?
1x, 3x or 7x your Average Daily Snowflake Credits, depending on whether monthly availability landed at or above 99.0%, between 95.0% and 99.0%, or below 95.0%. Its value therefore tracks your daily compute consumption, not your total invoice — which is why no dollar figure can be quoted for it in advance.
Am I owed a Snowflake credit if my queries were failing for ten minutes?
Possibly — and this is exactly the case the dual threshold exists for. Ten minutes of heavily failing queries will not breach a 99.9% monthly target on its own, but it can breach the 99.99% commitment measured at a 10% error rate. Check the month against both thresholds before concluding you have nothing.
Does the Snowflake SLA cover an AWS or Azure outage underneath my account?
The commitment is assessed per Cloud Provider Region, so the region your account runs in is the unit of measurement. Scheduled maintenance is excluded. Whether a specific upstream cloud event falls inside or outside the commitment depends on how the failure surfaced in your error rate — which is another reason to build the claim on your own query evidence rather than on a status-page narrative.
Methodology & caveats
The 99.9%/1%-error and 99.99%/10%-error thresholds, the 1x / 3x / 7x Average Daily Snowflake Credits bands, the non-cash and non-convertible nature of the credit, its application against the succeeding month's usage in the affected Cloud Provider Region, the 21-day request window and the scheduled-maintenance exclusion are transcribed from Snowflake's published Support Policy and Service Level Agreement into Ontracko's vendor profile. Snowflake revises that document — check the operative version and your own Order Form before filing, because negotiated agreements can differ from the public terms. The "roughly 3% of monthly compute" figure is our arithmetic on a 30-day month, not a Snowflake number. Snowflake's tariff and incident record are on its SLA page and status page; for vendors that do pay a percentage-of-fee credit with a live calculator, see MongoDB Atlas and the wider reliability rankings, which SaaS vendors actually pay SLA credits, SLA credit vs service credit and the SLA glossary.
*Snowflake's clock starts at month-end and runs 21 days, and the breach that owes you money may never look like an outage. Ontracko watches the Snowflake status feed, flags the month while the window is still open, and assembles the claim. Monitor Snowflake free — 8% only on recovered credits. See Snowflake live status or open the Snowflake SLA page.*
Related reading
How long do you have to claim an SLA credit? Deadlines by vendor
Every vendor puts a clock on your SLA credit — 15 days at Atlassian, 21 at Snowflake, 60 at AWS — and they don't all start counting from the same moment. Here's the deadline table, the three different clocks, and how to work out your own date.
Wall-clock uptime vs request success rate: how your SLA is actually measured
Two vendors can both promise 99.9% and mean completely different things. One counts minutes the service was down; the other counts failed requests as a share of total requests. Getting this wrong is the cleanest way to have an SLA credit claim denied.
How to claim an SLA credit from GitHub Enterprise Cloud
GitHub Enterprise Cloud owes a service credit when it misses its 99.9% uptime SLA — but the claim window is quarterly, not monthly, and starts after the quarter closes. Here's the credit schedule and how to file.
How to claim an SLA credit from MongoDB Atlas (99.995% uptime)
MongoDB Atlas commits to 99.995% uptime on M10+ dedicated clusters — about two minutes of allowed downtime a month. Miss it and you're owed 10% to 100% of that cluster's fee, but only if you log a ticket within 24 hours. Here's the credit table and the two-stage claim.
Or browse the SLA glossary and the reliability rankings.
Stop leaving SLA credits on the table
Ontracko monitors your vendors, catches every SLA breach, and drafts the claim. Free — 8% only on recovered credits.
Start monitoring free