Why do SLA credit claims get denied? The six exclusions that void a claim

Most SLA credit claims fail before anyone reads the uptime arithmetic. The outage was real, the status page recorded it, the minutes were counted correctly — and the vendor still owes nothing, because the downtime was excluded. The exclusion list, not the credit table, is where claims are actually decided.

The short answer

An SLA credit claim gets denied for one of six reasons, and only the last one is about the numbers. (1) Your plan tier isn't covered — most SLAs are Enterprise-only, and entry plans carry no remedy at all. (2) The downtime was scheduled or planned maintenance, which nearly every vendor carves out of the uptime calculation. (3) Your architecture disqualified you — single-node, single-zone and non-HA deployments are excluded by name at Google Cloud, Elastic, ClickHouse, PlanetScale, CockroachDB and Pinecone. (4) The outage was too short to count — LaunchDarkly excludes anything of 30 seconds or less, SendGrid anything under 5 minutes, monday.com read-only periods of 45 minutes or less. (5) The cause was a third party — another cloud provider, a carrier, the internet, a DDoS. (6) The cause was you — your configuration, your equipment, your credentials, or an unpaid invoice.

None of these is a loophole a vendor invents afterwards. They are published, they are specific, and they are checkable before you spend an hour assembling evidence.

1. Is your plan even covered?

This is the single most common denial, and it is decided before any outage happens. A vendor publishing "99.9% uptime" on a marketing page does not mean that commitment reaches your account.

Two further traps sit inside this row. Payment status is part of coverage: Grafana Cloud excludes any period in which an amount is past due, Confluent excludes late-payment suspension periods, Box excludes any period with past-due payments, and monday.com's SLA applies only to customers current on their payment obligations. And beta means uncovered nearly everywhere — GitHub, Cloudflare, Supabase, Vercel, Elastic, CockroachDB, ClickHouse, PlanetScale, Asana, Aiven and JumpCloud all carve out beta, preview or trial products explicitly.

Check this first. It takes thirty seconds and it decides the claim.

2. Does scheduled maintenance count against an SLA?

No — planned maintenance is excluded from the uptime calculation at essentially every vendor that publishes one. It appears in the exclusion list of AWS, Azure ("planned maintenance"), Google Cloud, GitHub, Datadog, Salesforce, Atlassian, Twilio, Snowflake, DigitalOcean, Linode, Postman, Mailgun, JFrog and many more.

What differs — and what is worth reading in your own vendor's terms — is how tightly the carve-out is bounded. Three shapes exist:

• Bounded with a notice requirement. Confluent requires 5 days' notice, ClickHouse 72 hours, SendGrid 24 hours or more, monday.com at least 3 days, JumpCloud "reasonable notice." If the vendor didn't give the notice its own SLA promises, the window arguably isn't excused maintenance.
• Bounded with a volume cap. Asana caps Service Maintenance at 360 minutes per fiscal quarter, Grafana at one planned window per quarter with 24 hours' notice, Aiven at one Periodic Maintenance Update per month with 7 days' notice, Twilio Segment at up to 5 hours per month. Exceed the cap and the excess is not excused.
• Unbounded. A bare "scheduled maintenance" exclusion with no window, no cap and no notice duty. This is the one that lets an outage be reclassified after the fact, and it is the most common form.

Two related carve-outs catch people out. Several vendors exclude emergency maintenance separately from scheduled maintenance — SendGrid and Twilio Segment both do — so "it wasn't on the maintenance calendar" is not by itself an argument. And Cloudflare's Enterprise SLA defines an Unscheduled Service Outage as one *not previously communicated to Customer*, which means the exclusion turns on whether you were told, not on whether it was planned.

3. Did your own architecture disqualify you?

This family is the least known and the most expensive, because the decision was made months before the outage, at deployment time. Many SLAs commit only to a specific redundant configuration and say nothing at all about anything less.

• Google Cloud excludes Preemptible VMs from the Compute Engine SLA, excludes non-HA instances from the Cloud SQL SLA, and notes that single-region Cloud Storage buckets carry a lower commitment than multi-region.
• ClickHouse Cloud covers only services configured with High Availability — fewer than 2 replicas and there is no commitment.
• PlanetScale excludes single-node clusters and development branches.
• CockroachDB Cloud states that single-node clusters never qualify.
• Pinecone excludes pod-based indexes not running at least two replicas for the whole month.
• Elastic Cloud excludes non-High-Availability deployments.
• Azure runs the mirror image: zone-redundant Azure SQL tiers commit 99.995% while the same tiers without zone redundancy commit 99.99%, so the configuration moves the threshold rather than removing it. Azure App Service excludes the Free and Shared tiers outright.
• MongoDB Atlas excludes clusters that have been up less than 24 hours.

The practical consequence: the availability number you are entitled to claim against is a property of what you deployed, not of what the vendor advertises. Before filing, confirm the configuration of the specific resource that went down — not the account, the resource.

4. Was the outage too short to count?

Several SLAs set a floor beneath which downtime is definitionally not downtime. A real, user-visible interruption can sit entirely inside that floor and be worth nothing.

These floors interact badly with flapping incidents. Five separate four-minute SendGrid interruptions in a month total twenty minutes of real impact and zero claimable minutes, because the floor applies per event, not per month. When you total downtime for a claim, total *qualifying* events — not every red bar on the status page.

5. Was the cause a third party?

Almost every SLA excludes causes outside the vendor's control, and for managed services running on someone else's infrastructure the carve-out is broader than it first sounds. Elastic Cloud, Confluent, ClickHouse, JFrog and PlanetScale all exclude failures of the underlying cloud provider by name; Pinecone excludes "failures of, or issues with, Cloud Providers." Twilio excludes carrier and downstream network issues. Grafana excludes external network conditions including DNS issues and peering disputes. Mailgun, monday.com and Postman exclude denial-of-service attacks.

This is where a single incident can produce a real claim against one vendor and no claim at all against another. When a cloud region fails and takes a managed database with it, the database vendor's SLA usually excludes it — and the cloud provider's SLA usually covers it, against whatever you spend with the cloud provider. File where the exclusion doesn't reach.

Cloudflare Workers makes the same point inside a single vendor: §3.2(b) excludes unavailability caused by the interdependent Cloudflare services a Worker relies on, naming CDN, DNS, WAF and storage bindings. Those are exactly the components the public status page most often reports on, so a Workers claim built on a CDN incident is refused by design. Confirm the incident is an incident of the service you are claiming against.

6. Was the cause on your side?

The last family is the most defensible denial and the easiest to avoid. Vendors consistently exclude customer-caused downtime, and the list is more specific than "your fault":

• Configuration and documentation. CockroachDB, ClickHouse, PlanetScale, Pinecone, Recurly and JFrog all exclude failures arising from not following the published documentation or configuration best practices. Datadog, DigitalOcean and Confluent exclude customer misconfiguration directly.
• Credentials and access. PlanetScale names misconfigured security groups, VPCs, credentials and inaccessible encryption keys. Cloudflare excludes a third party gaining access via your Authorized Users' accounts or equipment.
• Your own equipment and network. LaunchDarkly excludes customer computing devices, LANs and ISP connections. Azure excludes guest OS issues and third-party software running on your VM.
• Capacity you bought. CockroachDB excludes insufficient capacity or exceeding the request-unit budget; Aiven excludes customer load exceeding the service plan's resource capabilities. Outgrowing your plan is not an outage.
• Continuing after a warning. Cloudflare, and several vendors importing its Enterprise terms, exclude continued use after the vendor advised a modification.

How to check whether your outage is excluded before you file

1. Confirm your plan tier is in scope. Read who the SLA names — not who the marketing page names. If you're on Free, Standard, Pro or Team at most of the vendors above, stop here.
2. Confirm the account is in good standing. Past-due invoices void the remedy at Grafana, Box, Confluent and monday.com regardless of the outage.
3. Identify the exact resource that failed and its configuration. Single-node, single-zone, non-HA, preemptible or beta means check the architecture exclusions before anything else.
4. Check the vendor's maintenance record for that window. If it was announced maintenance, check whether the vendor met its own notice period and stayed inside any published cap — the excess is not excused.
5. Apply the minimum-duration floor, per event. Discard events shorter than the vendor's threshold, then total what remains.
6. Attribute the cause. If the root cause was another provider, the carrier, the internet or your own configuration, the claim belongs somewhere else — or nowhere.
7. Only now compute the uptime percentage against the surviving minutes, match it to the credit tier, and file inside the vendor's window. Claim deadlines vary from 15 to 60 days and several vendors require notice within hours.

Frequently asked questions

Why was my SLA credit claim denied?

Almost always because the downtime was excluded rather than mismeasured. The six exclusion families are: your plan tier isn't covered by the SLA, the downtime was scheduled or planned maintenance, your deployment configuration (single-node, single-zone, non-HA, preemptible, beta) falls outside the commitment, the outage was shorter than the vendor's minimum-duration floor, the cause was a third party such as another cloud provider or a carrier, or the cause was on your side — configuration, equipment, credentials or an unpaid invoice.

Does scheduled maintenance count as downtime under an SLA?

No. Scheduled and planned maintenance is excluded from the uptime calculation by essentially every vendor that publishes an SLA, including AWS, Azure, Google Cloud, GitHub, Atlassian, Twilio, Snowflake and DigitalOcean. The exclusion is sometimes bounded, though: Confluent requires 5 days' notice, ClickHouse 72 hours, SendGrid 24 hours, monday.com 3 days, and Asana caps maintenance at 360 minutes per fiscal quarter while Aiven allows one update per month. If the vendor did not give the notice or exceeded the cap its own SLA sets, the window is not cleanly excused.

Can a short outage be excluded from an SLA?

Yes. Some SLAs set a floor beneath which an interruption is not counted at all: LaunchDarkly excludes unavailability of 30 seconds or less, SendGrid excludes any single event under 5 minutes, monday.com excludes Read-Only Mode lasting 45 consecutive minutes or less, Smartsheet treats Service Modifications of up to one hour as Excused Downtime, and Webflow requires more than 30 consecutive minutes for downtime to qualify. The floor applies per event, so several short interruptions do not add up into a claim.

Does my SLA cover a single-node or non-HA deployment?

Usually not. ClickHouse Cloud covers only services with High Availability (at least 2 replicas), PlanetScale excludes single-node clusters and development branches, CockroachDB Cloud states single-node clusters never qualify, Pinecone excludes pod-based indexes without two replicas for the full month, Elastic Cloud excludes non-High-Availability deployments, and Google Cloud excludes Preemptible VMs and non-HA Cloud SQL instances. Azure works differently — zone-redundant SQL tiers commit 99.995% against 99.99% without, so the configuration moves the threshold rather than removing the remedy.

If my managed database went down because AWS went down, who owes me?

Typically the cloud provider, not the managed service. Elastic Cloud, Confluent, ClickHouse, JFrog, PlanetScale and Pinecone all exclude failures of the underlying cloud provider from their own SLAs, so the claim against them fails on attribution. The cloud provider's own SLA generally does cover the regional failure, against your spend with that provider. One incident, two vendors, and only one of them is claimable.

Do free or entry plans get SLA credits?

No, at most vendors. Atlassian's SLA applies to Cloud Premium and Enterprise only, GitHub's to Enterprise Cloud only, MongoDB Atlas's to M10+ dedicated clusters, Supabase's and Vercel's to Enterprise, Elastic's not at all to the Standard subscription, and monday.com's and Smartsheet's to Enterprise plans. Azure App Service excludes its Free and Shared tiers. A published uptime percentage is not the same thing as a contractual remedy on your plan.

Methodology & caveats

The plan-tier scopes, maintenance carve-outs, architecture requirements, minimum-duration floors and cause-based exclusions above are transcribed from each vendor's published SLA into Ontracko's vendor profiles, which is the same data the per-vendor SLA pages and credit calculators are built on. Where a vendor publishes no exclusion list of its own — Cloudflare R2 and Queues, for instance — the governing agreement's exclusions are the ones stated. Vendors revise these documents, negotiated enterprise terms differ from the published ones by design, and several of the shapes described here (Cloudflare's Unscheduled Service Outage definition, Azure's zone-redundancy split) turn on a single clause. Read your own agreement before asserting that any specific outage is or isn't excluded. Definitions for the terms used here are in the SLA glossary; for the credit tiers themselves see what an SLA credit is and what a 99.9% SLA actually allows.

*Ontracko records each vendor's exclusions alongside its credit tiers, so a detected incident is scored against the commitment that actually applies to your plan and configuration — and a claim isn't assembled for downtime the vendor has already carved out. Monitor your vendors free; 8% only on recovered credits. Start with the reliability rankings or your vendor's live status page.*