
The workload
Under Cloudflare's published Business Service Level Agreement, a customer who experiences an outage must notify support 'within five business days following the Incident' and then submit a full claim, with evidence, 'by the end of the billing month following the billing month in which the Incident...occurs,' verified — two separate deadlines, and missing either forfeits the claim. The document is explicitly scoped: it applies to 'Business Customers' and states 'If you are an Enterprise customer please refer to the Enterprise SLA,' verified, meaning a founder on Cloudflare's Enterprise plan is reading the wrong document if this is the only one found.
What the documents show
Verified: the Business SLA skips AWS-style percentage tiers for a flat target — '100% Uptime. The Service will serve Customer Content 100% of the time without qualification' — remedied by a formula: Service Credit equals outage minutes multiplied by the affected-customer ratio, divided by scheduled availability minutes. This research did not locate a public page for the separate Enterprise SLA the Business document points to; those terms appear to sit inside individual contracts rather than the open web. Separately, Cloudflare's own Trust Hub states, verified, that Cloudflare maintains 'posture around ISO 27001, ISO 27701, PCI DSS, SOC 2 Type II, and others' — certifications unrelated to the uptime commitment.
The operating cost
The formula produces a variable credit, but the Business SLA caps total annual exposure, verified: 'Service Credits awarded in any twelve (12) month period shall not...exceed one (1) month' of cumulative fees. The worst-case remedy, however bad the outage, is one month of the subscription back as a credit — not a cash payment, and not compensation for any downstream business the outage cost, a distinction that follows from the word 'credit' throughout rather than any explicit disclaimer.
The stop condition
The claim right lapses on the stated calendar, verified: five business days to notify, and the end of the following billing month to document it. Elsewhere on this site, a Cloudflare status-page incident postmortem records what actually happened during a specific outage; this entry only describes the contractual promise on a Business plan. Editorially, a founder evaluating Enterprise should treat the missing public SLA page as a reason to request the actual document before assuming any Business SLA term carries over.
- Which Cloudflare plan does the account actually sit on, and has the corresponding SLA document, not just the pricing page, been read?
- Does the 100%-uptime target with a formula-based credit change how an outage should be logged, compared with a tiered-percentage SLA like AWS's?
- If moving to Enterprise, has Cloudflare's sales or account team supplied the actual Enterprise SLA text rather than a reference to it?
A published SLA is evidence of what one plan tier promises, not of what every tier receives. Cloudflare's own Business document draws that line itself by naming a separate agreement it does not publish, which is the more useful fact here than either document's specific numbers.
Sources & reading trail
States the 100% uptime target, the formula-based service credit, exclusions, claim deadlines, the annual credit cap, and that Enterprise customers are referred to a separate SLA.
Source published: Not established · Retrieved: 16 September 2026
States Cloudflare's own claimed certifications (ISO 27001, ISO 27701, PCI DSS, SOC 2 Type II), distinct from the SLA's uptime commitment.
Source published: Not established · Retrieved: 16 September 2026
Vendor documentation, regulator records and founder-published documents establish the entry; the workload reading and the stop condition are Solo Product Office editorial analysis. This retrospective draft does not imply the site published on the event date.