How long do you have to claim an SLA credit? Deadlines by vendor

Every SLA credit has an expiry date, and it's usually sooner than people assume. The outage is the easy part — the part that costs teams money is filing after the window closed. Here's how long each major vendor actually gives you, and why two vendors that both say "30 days" can have deadlines three weeks apart.

The short answer

Most vendors give you 15 to 60 days to claim an SLA credit, and the clock does not start at the outage for most of them — it starts at the end of the billing month (AWS, Azure, Atlassian, Twilio, Cloudflare, MongoDB Atlas, Snowflake) or at the end of the calendar quarter (GitHub Enterprise Cloud). Google Cloud is the notable exception: its 30 days run from the incident itself, which makes it the tightest real deadline among the big three clouds. Several vendors also impose an earlier notice deadline — Cloudflare wants notice within 5 business days, MongoDB Atlas within 24 hours — that kills the claim before the main window ever matters. Miss the window and the credit is gone; there is no appeals channel for a late filing.

Claim deadlines by vendor

These are the windows Ontracko holds in its SLA profiles for the vendors it can substantiate a credit for:

Three more vendors belong here for the opposite reason. Datadog's standard MSA carries no filable service credit at all — the only remedy is a termination right after two consecutive months below its availability target. Twilio Segment's Data Ingestion API SLA is the same shape: a special termination right, exercisable within 30 days of reasonably becoming aware of the failure, rather than a credit. For both, the date that matters is renewal leverage, not a claim deadline. Salesforce publishes no standard credit tariff — its credits are governed by whatever your MSA says, so your deadline lives in your own agreement, not on a public page.

Why "30 days" doesn't mean the same thing twice

The most expensive misunderstanding in SLA claims is assuming the clock starts when the outage ends. Across the vendors above there are three different starting points.

The incident. Google Cloud counts 30 days from when you became eligible for the credit — effectively from the outage. That is the shortest practical runway of any major cloud, and it's the one teams miss most often: by the time finance closes the month and someone notices the spend, the window has already shut.

The end of the billing month. Most payers work this way. AWS, Azure, Atlassian, Twilio, Cloudflare, MongoDB Atlas and Snowflake all measure uptime per calendar month, so a claim can't be finalised until the month is over — an outage on the 3rd and an outage on the 28th share one deadline. This is why Atlassian's 15 days is far tighter than it sounds when the outage was early in the month: you sat on it for six weeks before the clock even started.

The end of the quarter. GitHub Enterprise Cloud measures its 99.9% commitment across the calendar quarter, so a January outage isn't claimable until Q1 closes on March 31 — and then you have 30 days. A longer runway, but a slower cycle, and you can't file early even if you want to.

Ontracko records this as a per-vendor *deadline basis* and computes both dates for every claim: a conservative floor counted from the incident, and the authoritative last date to file counted from the billing cycle or quarter. The later date is the real deadline — the earlier one is the date you should work to.

The notice deadline that kills claims before they start

Three vendors run a two-stage process, and the first stage is where most claims die:

• MongoDB Atlas requires a support ticket within 24 hours of becoming aware of the downtime. Miss that and the full claim — due by the end of the following month — is void before you write it.
• Cloudflare wants notice within 5 business days of the incident, with the formal claim following by the end of the next billing month.
• Atlassian expects an incident ticket raised during the outage, then a separate Cloud Premium/Enterprise SLA compensation request afterwards.

If you only ever act at month-end, you will systematically forfeit credits at these three vendors no matter how well you document the outage. The fix is procedural, not analytical: a same-day ticket, filed while the status page still says "investigating."

How to work out your own claim deadline

1. Identify the vendor and the exact incident window — start and end timestamps from the vendor's own status page, not from your internal alerting.
2. Check whether that vendor demands notice first (24 hours at MongoDB Atlas, 5 business days at Cloudflare, an in-incident ticket at Atlassian). If so, file that ticket today, before doing any arithmetic.
3. Find the vendor's measurement period — monthly for most, quarterly for GitHub Enterprise Cloud — and mark the date that period ends.
4. Add the vendor's filing window to that end date: 15 days for Atlassian, 21 for Snowflake, 30 for Twilio and GitHub, roughly 60 for AWS and Azure. For Google Cloud, count 30 days from the incident instead.
5. Confirm your plan is actually covered. Entry tiers usually carry no SLA at all — Atlassian Free and Standard, MongoDB's Flex and shared clusters, Cloudflare Free and Pro, GitHub Free/Pro/Team.
6. Measure the period's uptime against the commitment, match it to the credit tier, and file with the vendor's required evidence before the date from step 4.

What happens if you miss it

Nothing dramatic — which is the problem. The vendor doesn't reject a late claim with a fight; it simply declines it, and there is no appeals path for a missed window. A legitimate breach with clean evidence is worth exactly zero the day after the deadline. That asymmetry is the whole reason vendors publish these windows: the credit is real, but it is opt-in, and the burden of noticing, measuring and filing on time sits entirely with the customer.

It is also why the deadline, not the credit percentage, is usually the number worth automating. A 10% credit you file on time beats a 25% credit you work out in week nine.

Frequently asked questions

How long do I have to claim an SLA credit?

It depends on the vendor: 15 days after month-end at Atlassian, 21 days at Snowflake, 30 days at Twilio, 30 days from the incident at Google Cloud, 30 days after quarter-end at GitHub Enterprise Cloud, and roughly 60 days after the billing month at AWS and Azure. Check the starting point as well as the length — that is what varies most.

Does the SLA credit deadline start at the outage or at the end of the month?

For most vendors, the end of the billing month. AWS, Azure, Atlassian, Twilio, Cloudflare, MongoDB Atlas and Snowflake all measure uptime monthly, so the window runs from month-end. Google Cloud is the exception — its 30 days run from the incident. GitHub Enterprise Cloud runs from the end of the calendar quarter.

Which vendor has the shortest SLA credit deadline?

By notice requirement, MongoDB Atlas: a support ticket within 24 hours of noticing the downtime, or the claim is dead. By filing window, Atlassian's 15 days after month-end is the tightest of the major payers, and Google Cloud's 30 days is the shortest among the big three clouds because it counts from the incident rather than month-end.

Can I still claim an SLA credit after the deadline has passed?

Generally no. The claim window is a condition of the credit, not a guideline, and vendors decline late filings without an appeals channel. What's left is commercial rather than contractual — a documented pattern of missed SLAs is still worth raising at renewal even when the individual credits have expired. See what an SLA credit is for where the credit remedy sits inside the agreement.

Do free plans have an SLA credit deadline?

There is usually nothing to claim. Entry tiers typically carry no uptime commitment at all — Atlassian Free and Standard, Cloudflare Free and Pro, GitHub Free/Pro/Team, and MongoDB's Flex and shared clusters are all excluded from their vendors' SLAs. See which SaaS vendors actually pay SLA credits for who pays, and on which plans.

How do I track SLA credit deadlines across many vendors?

Either a recurring calendar task per vendor keyed to that vendor's measurement period, or monitoring that computes the deadline for you the moment an incident is detected. Ontracko does the latter: it tracks every monitored vendor's incidents, derives the notice and filing dates from that vendor's deadline basis, and marks a claim expired rather than letting it quietly lapse.

Methodology & caveats

Every window, notice requirement and measurement period above is transcribed from the vendor's published SLA into Ontracko's per-vendor SLA profile — the same profile that drives its deadline calculations. Terms change, and enterprise order forms frequently override the public document, so verify against your own agreement before relying on a date. Snowflake in particular has two circulating SLA versions (a 99.9% / 21-day published PDF and a stricter later variant); confirm which one your Order Form references. Live incident history for every vendor named here is on its status page — see Google Cloud, AWS, or the full reliability rankings. The terms used above are defined in the SLA glossary. For the per-vendor filing mechanics behind these dates, see the guides for AWS, Google Cloud, Atlassian, MongoDB Atlas and GitHub.

*Ontracko monitors 144 SaaS and cloud vendors' status feeds, computes the notice and filing deadlines for every detected breach, and assembles the claim before the window closes. Free monitoring — 8% only on credits recovered. See live vendor status or open the SLA credit calculators.*