How to claim an SLA credit from Cloudflare
Cloudflare's Enterprise SLA commits to 100% uptime and pays a formula-based credit. The stage that kills most claims is the notice of intent, due within 5 business days — and Workers, R2 and Queues are governed by their own separate SLAs.
Cloudflare is unusual twice over. Its Enterprise SLA commits to 100% uptime, not 99.9%, so any qualifying outage is a breach. And its claim process has two stages, the first of which expires in five business days — which is what actually stops most Cloudflare claims, long before the arithmetic matters.
The short answer
Under the Cloudflare Enterprise Customer Support and Service Level Agreement (policy date 1 April 2026), Cloudflare commits to serving your content 100% of the time. To claim, you must do two separate things:
- Within 5 business days of the incident, notify Cloudflare of the specific incident and of your intention to submit a claim (§7.1). Miss this and the claim is dead regardless of what you do next.
- Before the end of the billing month immediately following the billing month in which the incident occurred (§7.2), submit the formal claim with your evidence.
The credit is a formula, not a tier table, and it is applied to your Monthly Fee. Workers, R2 and Queues are not covered by this SLA — each has its own, with its own commitment and its own credit table.
Three separate SLAs, not one
This is the part most guides get wrong, including an earlier version of this one. Section 12.1 of the Enterprise SLA names three services that carry a Service-Specific SLA which controls over the Enterprise terms for claims about that service:
| Service | Commitment | Credit | Measured over |
|---|---|---|---|
| Everything else | 100% | formula × your success-package multiplier | the monthly billing period |
| Workers | 99.99%, on a commercially-reasonable-efforts basis | 10% / 25% / 50% | a rolling 30-day period |
| R2 | 99.9% | 10% / 25% / 50% | a rolling 30-day period |
| Queues | 99.9% | 10% / 25% / 50% | a rolling 30-day period |
Two consequences worth knowing before you file:
- You may not claim under both. Each service-specific SLA says plainly that customers may not submit a claim under it *and* the Enterprise SLA for the same incident. Picking the instrument is a real decision, not a formality.
- The fee bases are different. The Enterprise "Monthly Fee" (§1.6) explicitly excludes fees for any service subject to a service-specific SLA, and it is the fee paid in the billing month *preceding* the incident. The Workers, R2 and Queues credits are instead a percentage of that service's usage fees in the 30 days preceding submission of the claim — a base that moves depending on when you file.
What the 100% commitment actually covers
Section 2.2 commits that the Service "will serve Customer Content globally 100% of the time". But the thing being counted is an Unscheduled Service Outage, defined in §1.14 as an interruption that was not previously communicated to you and that results in your websites being unavailable to your own End Users. A Cloudflare status-page incident that never made your sites unavailable is not an Outage Period, however visible it was.
The denominator is Scheduled Availability (§1.12): the total number of minutes in a given month, minus any downtime you asked Cloudflare for.
How the credit is calculated
Section 10.1 provides a credit for each Outage Period during a monthly billing period, "calculated in accordance with the formula below that is applicable to the Customer's success package". The formula's inputs are named in the agreement — the Outage Period (§1.7), the Affected Customer Ratio (§1.1), and Scheduled Availability (§1.12) — and the multiplier depends on which success package you bought.
Cloudflare publishes the formula itself, and the Affected Customer Ratio definition, only as images. Neither figure appears as text in the current agreement or in the archived November 2020 version, so we do not reproduce a multiplier here. Open the SLA page, read the two images in sections 1.1 and 10.1, and apply the multiplier for your own success package.
Two limits that do appear in the text:
- Credits are calculated against your fixed Monthly Fees (§9.4).
- Total credits in any annual billing period cannot exceed six months of your cumulative Monthly Fees (§9.3).
The Cloudflare SLA guide shows the filing process rather than an auto-calculated tier, because the multiplier is not something we can read from the document.
The evidence Cloudflare expects
Section 7.2 asks for "reasonable details and sufficient evidence", and names:
- Detailed descriptions of the incident
- The duration of the incident
- Network traceroutes
- The URLs affected
- Any steps you took to resolve it
Plus, from §11.1, the one people miss: Cloudflare states that comprehensive monitoring of your content is your responsibility, and that it will consider supporting data only where it was "obtained using a commercially reasonable independent measurement system used by Customer". Your own monitoring record is not a nice-to-have here; the agreement asks for it by name.
How to claim a Cloudflare SLA credit
- Today, if the incident was in the last five business days: open a support case or email success@cloudflare.com stating the specific incident and that you intend to claim. Do this before any arithmetic — §7.1 is the stage that expires first.
- Confirm which SLA governs. If the affected service is Workers, R2 or Queues, use that service's own SLA and its tier table, and do not also claim under the Enterprise SLA for the same incident.
- Record the outage window and the Cloudflare incident reference from the status page, together with your own independent monitoring record.
- Work out the credit: for the Enterprise SLA, read the multiplier off the images in §1.1 and §10.1 for your success package; for Workers, R2 or Queues, read your uptime against the 10/25/50 bands.
- Submit the formal claim before the end of the billing month following the billing month of the incident, with the traceroutes and affected URLs attached.
Watch the exclusions
Section 8.1 excludes issues caused by your own or your End Users' hardware, software or connectivity; corrupted content; acts or omissions of you or your agents; a third party getting in through your authorised users' accounts; your continued use after Cloudflare advised you to change it; and anything during beta or trial services.
Workers carries an extra exclusion that matters more than any of those. Section 3.2(b) of the Workers SLA excludes unavailability caused by "the unavailability or performance degradation of interdependent Cloudflare services upon which the Worker relies (including but not limited to Cloudflare CDN, DNS, WAF, specialized storage bindings)". A CDN or DNS outage — which is exactly what a Cloudflare status-page incident usually reports — does not count against the Workers commitment. Section 3.2(a) also excludes your own misconfiguration: custom 500/503 responses from your script, bad route triggers, misconfigured bindings, mismanaged secrets, or exceeding CPU and memory limits.
Cloudflare's self-serve plans are governed by a different agreement, which Ontracko has not read. Nothing on this page describes what a Free, Pro or Business plan is owed; check your own agreement.
Frequently asked questions
How long do I have to claim a Cloudflare SLA credit?
Two deadlines, and the first is the one that bites. Notice of intent is due within 5 business days of the incident (§7.1). The formal claim is due before the end of the billing month immediately following the billing month in which the incident occurred (§7.2) — so the clock does not run from the outage date, but the notice deadline does.
Does Cloudflare really commit to 100% uptime?
Yes, in §2.2 of its Enterprise SLA — but for a specific quantity. The commitment is measured against Unscheduled Service Outages, which §1.14 defines as interruptions that left your websites unavailable to your own End Users. It does not turn every status-page incident into a credit.
Are Cloudflare Workers covered by the 100% SLA?
No. Workers has its own SLA committing to a 99.99% Monthly Uptime Percentage on a commercially-reasonable-efforts basis, measured over a rolling 30-day period from request error rates, with a 10/25/50% credit table. R2 and Queues each have their own at 99.9%. You cannot claim under one of these and the Enterprise SLA for the same incident.
How is Cloudflare's credit different from AWS or Google Cloud?
AWS and Google Cloud use tiered percentages based on which uptime band you fell into. Cloudflare's Enterprise SLA uses a continuous formula scaled by your success package, so the credit varies with the outage rather than jumping between bands — but its Workers, R2 and Queues SLAs are conventional tier tables, so Cloudflare uses both shapes depending on the service.
Methodology & caveats
The commitment, the two-stage deadline, the exclusions, the cap and the fee base on this page are transcribed from Cloudflare's Enterprise Customer Support and Service Level Agreement (policy date 1 April 2026), and the per-service terms from the Workers, R2 and Queues SLAs, all read on 7 September 2026. We do not publish the credit multiplier, because Cloudflare publishes it only as an image and we will not reproduce a figure we cannot cite to text. Self-serve plans are governed by a separate agreement we have not read. Live Cloudflare incident history is on its status page.
*Ontracko monitors Cloudflare's public status feed, detects SLA breaches, and assembles the claim package. Free — 8% only on recovered credits. See Cloudflare live status or the Cloudflare SLA guide.*
Related reading
Does OpenAI or Anthropic owe you an SLA credit when the API goes down?
OpenAI prints a 99.9% uptime SLA on its Scale Tier and Fast mode pages — for Enterprise customers only — but publishes no credit schedule, no uptime definition and no claim window. Anthropic publishes nothing at all and disclaims uninterrupted service by name. Here is what each one actually owes you.
Why do SLA credit claims get denied? The six exclusions that void a claim
A real outage is not the same thing as claimable downtime. Six exclusion families — plan tier, scheduled maintenance, your architecture, minimum-duration floors, third-party carve-outs and your own configuration — decide whether a vendor pays. Here is how each one works, with the vendors that use it.
DigitalOcean SLA credit: how the 99.99% Droplet guarantee pays out (and how to claim it)
DigitalOcean's CPU Droplet SLA commits to 99.99% monthly uptime per Droplet and pays a 100% service credit below it — no tiers. Here is what counts as downtime, what the credit covers, the two-billing-cycle deadline and the exact email to send.
Does Salesforce pay SLA credits? What its agreement actually commits to
Salesforce publishes no uptime percentage, no credit schedule and no filing window — its agreement promises only commercially reasonable efforts. Here is where your Salesforce SLA actually lives, and what to do after an outage.
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