Cloudflare SLA credit guide

Credits for Cloudflare Enterprise SLA (services without their own SLA) are governed by your contract (MSA/order form), not a published tier table. THIS IS THE ENTERPRISE SLA AND IT DOES NOT GOVERN WORKERS, R2 OR QUEUES. §12.1 names those three as carrying their own Service-Specific SLA which CONTROLS for a claim about that service, and §1.6 excludes their fees from the "Monthly Fee" this agreement's credit is computed against. Each has its own row in this catalog, its own commitment and its own credit table — and you MAY NOT claim under a service SLA and this one for the same Incident. TWO-STAGE FILING: (1) §7.1 — notice of intent within 5 BUSINESS days following the Incident, to success@cloudflare.com; (2) §7.2 — the Claim itself before the end of the billing month immediately following the billing month in which the Incident occurred. WHAT IS BEING COUNTED: §1.14 defines an Unscheduled Service Outage as an interruption not previously communicated to you AND one that results in your websites being unavailable to your own End Users — a status-page incident that never took your sites down is not an Outage Period, however visible it was. THE CREDIT IS A FORMULA AND CLOUDFLARE PUBLISHES IT ONLY AS AN IMAGE: §1.1 (Affected Customer Ratio) and §10.1 (Service Credit Calculation) are pictures in the current agreement and in the archived 2020 version alike, so Ontracko states NO multiplier — any figure you have seen quoted for one is not in Cloudflare's text. What the text does state is what the formula is built from: the Outage Period in minutes (§1.7), the Affected Customer Ratio, which Cloudflare estimates from its own service data (§11.2), Scheduled Availability — the total minutes in a given month less Customer Planned Downtime (§1.12) — and a multiplier applicable to YOUR OWN success package (§10.1). Read that multiplier off the images at https://www.cloudflare.com/enterprise-support-sla/ against the package you actually bought. LIMITS: credits are calculated against fixed Monthly Fees unless a Service-Specific SLA says otherwise (§9.4), and total credits in an annual billing period cannot exceed six months of cumulative Monthly Fees (§9.3). NOTE THE FEE BASE IS THE MONTH BEFORE: §1.6 anchors the Monthly Fee to the billing month PRECEDING the Incident, not the month of it. EVIDENCE: §11.1 puts monitoring on you — Cloudflare is not responsible for comprehensive monitoring of your content and will consider supporting data obtained using a commercially reasonable independent measurement system used by Customer, so bring your own record. SCOPE OF THIS TRANSCRIPTION: the Enterprise agreement only. Cloudflare's self-serve plans are governed by a different document Ontracko has not read, and nothing here states what one is owed.

Measured how? Cloudflare Queues is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Cloudflare can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.

A percentage of what? Cloudflare Queues’s credit is a percentage of the fees paid for Queues usage in the thirty days preceding submission of a valid Claim (§3.1) — not the month of the incident, and not your Monthly Fee — not of your invoice. The Credit column above is that percentage, and it converts to no dollar figure we can compute for you, because that base is not a figure Ontracko holds — quote the tier and ask Cloudflare to apply it to the base its own SLA sets.

GOVERNED BY THE QUEUES SLA, NOT THE ENTERPRISE SLA — §12.1 of the Enterprise agreement says this service's own SLA CONTROLS, so the 100% commitment on the Cloudflare wildcard row does not apply to Queues. ⚠️ YOU MAY NOT CLAIM UNDER BOTH: §3.2 states that customers may not submit a Claim under this Queues SLA and the Enterprise Customer Support and Service Level Agreement related to the same Incident, so the instrument is a choice — the Queues tariff is a fixed 10/25/50 band on Queues usage fees, the Enterprise route is a formula on your Monthly Fee that EXCLUDES Queues fees (§1.6). ⚠️ THE CREDIT BASE MOVES WITH WHEN YOU FILE: §3.1 pays a percentage of the fees paid for Queues usage in the THIRTY DAYS PRECEDING SUBMISSION of a valid Claim — not the month of the incident, and not your Monthly Fee. THE OBLIGATION IS UNHEDGED, unlike Workers': §2.1 says Cloudflare WILL PROVIDE a Monthly Uptime Percentage of 99.9%, with no "commercially reasonable efforts" qualifier. HOW IT IS MEASURED: §1.1 counts requests to a Queues endpoint answered with a 500/502/503/504 OR AN ERROR CODE OF 15000 OR ABOVE — a wider error set than the R2 and Workers SLAs use — as a share of total Valid Requests in each 5-MINUTE INTERVAL, and §1.2 averages those over a THIRTY (30) DAY period. Cloudflare calls the result a "Monthly Uptime Percentage", but the window is thirty days and the input is requests. Ontracko scores status-page incident duration, which is WALL CLOCK, so our figure is an ESTIMATE of a quantity only Cloudflare can compute from its own request logs: the status-page record is evidence that a qualifying event happened, not the contractual figure. FILING: §3.2 imports the Enterprise SLA's claim requirements wholesale — notice of intent within 5 BUSINESS days (§7.1), formal claim before the end of the billing month following the Incident's billing month (§7.2). Credits are the sole and exclusive remedy.

Measured how? Cloudflare R2 is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Cloudflare can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.

A percentage of what? Cloudflare R2’s credit is a percentage of the fees paid for R2 usage in the thirty days preceding submission of a valid Claim (§3.1) — not the month of the incident, and not your Monthly Fee — not of your invoice. The Credit column above is that percentage, and it converts to no dollar figure we can compute for you, because that base is not a figure Ontracko holds — quote the tier and ask Cloudflare to apply it to the base its own SLA sets.

GOVERNED BY THE R2 SLA, NOT THE ENTERPRISE SLA — §12.1 of the Enterprise agreement says this service's own SLA CONTROLS, so the 100% commitment on the Cloudflare wildcard row does not apply to R2. ⚠️ YOU MAY NOT CLAIM UNDER BOTH: §3.2 states that customers may not submit a Claim under this R2 SLA and the Enterprise Customer Support and Service Level Agreement related to the same Incident, so the instrument is a choice — the R2 tariff is a fixed 10/25/50 band on R2 usage fees, the Enterprise route is a formula on your Monthly Fee that EXCLUDES R2 fees (§1.6). ⚠️ THE CREDIT BASE MOVES WITH WHEN YOU FILE: §3.1 pays a percentage of the fees paid for R2 usage in the THIRTY DAYS PRECEDING SUBMISSION of a valid Claim — not the month of the incident, and not your Monthly Fee. THE OBLIGATION IS UNHEDGED, unlike Workers': §2.1 says Cloudflare WILL PROVIDE a Monthly Uptime Percentage of 99.9%, with no "commercially reasonable efforts" qualifier anywhere in the sentence. HOW IT IS MEASURED: §1.1 counts Valid Requests to an R2 bucket returning 500/502/503/504 as a share of total Valid Requests in each 5-MINUTE INTERVAL, and §1.2 averages those over a THIRTY (30) DAY period — Cloudflare calls the result a "Monthly Uptime Percentage", but the window is thirty days and the input is requests. Ontracko scores status-page incident duration, which is WALL CLOCK, so our figure is an ESTIMATE of a quantity only Cloudflare can compute from its own request logs: the status-page record is evidence that a qualifying event happened, not the contractual figure. FILING: §3.2 imports the Enterprise SLA's claim requirements wholesale, so notice of intent is due within 5 BUSINESS days (§7.1) and the formal claim before the end of the billing month following the Incident's billing month (§7.2). R2 publishes no exclusion list of its own — the Enterprise SLA's §8.1 exclusions are the ones that apply. Credits are the sole and exclusive remedy.

Measured how? Cloudflare Workers is measured as a request success rate — errors as a share of total requests, averaged over short intervals — not as wall-clock uptime. Availability for this service is the vendor’s Monthly Uptime Percentage under that definition, which only Cloudflare can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.

A percentage of what? Cloudflare Workers’s credit is a percentage of the fees paid for Workers usage in the thirty days preceding submission of a valid Claim (§3.1) — not the month of the incident, and not your Monthly Fee — not of your invoice. The Credit column above is that percentage, and it converts to no dollar figure we can compute for you, because that base is not a figure Ontracko holds — quote the tier and ask Cloudflare to apply it to the base its own SLA sets.

GOVERNED BY THE WORKERS SLA, NOT THE ENTERPRISE SLA — §12.1 of the Enterprise agreement says this service's own SLA CONTROLS, so the 100% commitment on the Cloudflare wildcard row does not apply to Workers and never did. ⚠️ YOU MAY NOT CLAIM UNDER BOTH: §3.3 states that customers may not submit a Claim under this Workers SLA and the Enterprise Customer Support and Service Level Agreement related to the same Incident, so choosing the instrument is a real decision — the Workers tariff is a fixed 10/25/50 band on Workers usage fees, the Enterprise route is a formula on your Monthly Fee that EXCLUDES Workers fees (§1.6). ⚠️ THE CREDIT BASE MOVES WITH WHEN YOU FILE: §3.1 pays a percentage of the fees paid for Workers usage in the THIRTY DAYS PRECEDING SUBMISSION of a valid Claim — not the month of the incident, and not your Monthly Fee. ⚠️ AN OUTAGE OF CLOUDFLARE CDN, DNS OR WAF DOES NOT COUNT: §3.2(b) excludes unavailability resulting from the unavailability or performance degradation of interdependent Cloudflare services the Worker relies on, naming CDN, DNS, WAF and specialized storage bindings — which is exactly what the cloudflarestatus.com feed most often reports. Check the incident is a Workers incident before filing. HOW IT IS MEASURED: §1.1 counts Valid Requests returning a non-custom 500/502/503/504 (throttled and rate-limited requests excluded) as a share of total Valid Requests in each 5-MINUTE INTERVAL, and §1.2 averages those over a THIRTY (30) DAY period — Cloudflare calls the result a "Monthly Uptime Percentage", but the window is thirty days and the input is requests. Ontracko scores status-page incident duration, which is WALL CLOCK, so our figure is an ESTIMATE of a quantity only Cloudflare can compute from its own request logs: the status-page record is evidence that a qualifying event happened, not the contractual figure. FILING: §3.3 imports the Enterprise SLA's claim requirements wholesale, so the two-stage process still governs — notice of intent within 5 BUSINESS days (§7.1), formal claim before the end of the billing month following the Incident's billing month (§7.2). Credits are the sole and exclusive remedy.