Measured in your browserWe advise on speed. We practice it.Loaded just now · real numbers from this visit, not a lab score.
Page loaded
First byte
DOM ready
First paint
Largest paint
DNS lookup
TLS handshake
Transferred
Saved by compression
Requests

Service credits are the SLA’s enforcement mechanism, and they share a design across the industry: defined narrowly, measured by the vendor, claimed by the customer, on a deadline. Nothing about that process favours the passive — credits are claimed, not granted — and the claiming skill is 80% preparation done before any incident: knowing the definitions, running the independent monitoring, and having the ledger ready. Here is the end-to-end, plus the honest word on what credits are worth.

Read the SLA before you need it

Every SLA answer lives in four definitional clauses, best read on a calm afternoon. Measurement: what counts as unavailability — whose monitoring, at what granularity, region-wide or per-service, and whether degradation (elevated errors, latency) counts or only hard downtime; many CDN SLAs measure availability in ways that a miserable-but-partial hour never breaches. Exclusions: maintenance windows, force majeure, “factors outside our control,” issues attributed to customer configuration — the clause where claims go to die, worth knowing verbatim. Remedy schedule: the table mapping breach severity to credit size, typically percentages of the monthly fee for the affected service. Process: notification window (often 15–30 days from incident), required evidence, and where claims are filed. Summarize the four onto one page in your incident runbook — the version from reading a CDN contract — because incident day is a reading-comprehension environment nobody should trust.

Evidence: yours, timestamped, independent

The vendor’s measurements decide the SLA’s letter, but your independent evidence decides the conversation — and sometimes the outcome, because vendor monitoring has blind spots (regional partial failures, in particular) that a well-evidenced claim gets escalated past. The kit is what the outage playbook already runs: external synthetic probes with timestamps and regions, RUM error-rate curves, and the incident log capturing detection time, symptoms, provider status-page timeline, and support-ticket numbers. During any qualifying incident, capture as you go — screenshots of their status page (which gets edited), probe results exported, ticket timestamps — because reconstructing evidence two weeks later, inside a claim deadline, is exactly the misery preparation exists to prevent. The habit costs minutes per incident and converts every claim from an assertion into an exhibit.

The claim itself: process and deadlines

File every eligible claim, promptly and boringly. The deadline is the trap — a 15-day notification window expires while teams are still writing the internal postmortem, so make “file the SLA claim” a standing checklist item in incident closure, owned by a name. The claim document: incident window (their timeline and yours), affected services and hostnames, the SLA clause invoked, your evidence pack attached, and the remedy requested per the schedule — neutral in tone, precise in citation; claims argued emotionally get handled procedurally, claims argued procedurally get handled quickly. Expect the first response to test the exclusions; answer with evidence, escalate through the account team where the technical channel stalls, and put persistent disputes on the QBR register where they acquire owners and dates in front of people with authority.

Expectations: what credits are worth

Now the honest calibration. Credits are percentages of monthly fees — a serious breach might return 10–30% of one month for the affected service — while your incident cost was measured in lost revenue, engineering hours and reputation: credits are not compensation and were never designed to be; SLAs cap liability far more than they transfer risk. Claim them anyway, for three better reasons. The money is real, if modest, and claiming it is nearly free once prepared. The record matters more: a documented pattern of breaches and claims is renewal-season evidence no anecdote matches, and inside some contracts repeated breaches unlock termination rights — check yours. And the signal disciplines the relationship: vendors triage attention toward customers who measure, file, and follow up. If your downtime cost genuinely dwarfs any credit, the SLA is telling you the answer lives elsewhere — in architecture, per the multi-CDN scorecard, not in a remedy table.

The credit ledger and the bigger game

Keep one ledger: incident, date, SLA position, claim filed (date), outcome, credit received, and the delta between your measured impact and their acknowledged impact. Reconcile granted credits against invoices — credits have a way of being approved and never appearing, which the monthly review catches in its fifteen minutes. Roll the ledger up twice a year: into the QBR, where the pattern (or its absence) is discussed with the account team, and into the annual review, where credits-claimed-vs-impact-suffered becomes one exhibit in the reliability story — alongside SLO attainment — that decides whether next year’s answer is a harder negotiation, an architectural change, or contentment. That is the bigger game credits actually serve: not the refund, but the documented, dated, dollar-annotated case for whatever you decide to do next.

Get the free assessmentMore analysis