Duo Security SLA credit guide

Measured how? Duo Security (paid plans — Cisco Duo SLA v1.2) 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 Duo Security can compute from its request logs. A status-page outage is evidence that a qualifying event happened; it is not the contractual figure.

Credited in what? Duo Security (paid plans — Cisco Duo SLA v1.2)’s credit is denominated in Service Days added to the end of the subscription term, non-cash, not as a share of the fees you pay. The Credit column above is in that unit, and it converts to no dollar figure we can compute for you — ask Duo Security to apply the credit its own SLA describes.

A VERIFIED PAYER WHOSE CREDIT IS NOT MONEY. Source: "Service Level Agreement — Duo", Version 1.2, December 9, 2025, marked Cisco Public, served from the Cisco Trust Portal; duo.com/legal/sla — the URL Cisco's own MSLA Product Terms – Duo cites ("1.4 Service Level Agreement. Use of Duo is subject to the Service Level Agreement available at https://duo.com/legal/sla.") — 301-redirects there. THE STANDARD: "During each Measurement Period, the Availability of the Core Services will be 99.99% or greater", where "Core Services" means the "Duo Security multi-factor authentication service" and the Measurement Period is "One calendar month". ⚠️ THE CREDIT IS SERVICE DAYS, NOT A PERCENTAGE AND NOT CASH, AND TABLE 2 DOES NOT SAY SO IN THE TABLE: the four figures print as a bare "3 / 7 / 10 / 15" against the availability bands, and the unit appears only in the paragraph beneath — "Service days: If You are entitled to a Service Credit, additional days of Cisco Offer use in the amount and type listed in Table 2 ('Service Days') will be added to the end of Your existing Cisco Offer Usage Term." Anyone who transcribes the table alone publishes four percentages. It is also expressly non-convertible: "You cannot convert the Service Credit to general credits or refunds, and You cannot sell, transfer, or assign the Service Credit." So there is no dollar figure to quote and Ontracko states none. THE BANDS, exactly as printed: <99.99% – >=99.9% → 3; <99.9% – >=99.00% → 7; <99.00 – >=95.00% → 10; <95.0% → 15. CAP: "The aggregate maximum Service Credit for any Measurement Period will be 15 Service Days" (§2.2) — the same figure as the bottom band. EXCLUSIVE REMEDY, and it eats into the liability cap: "A Service Credit is Your sole and exclusive remedy... Any Service Credit provided under this SLA will count toward the limitation of Cisco's liability under Your applicable agreement" (§2.3). ⏰ THERE ARE TWO CLOCKS AND THE EARLIER ONE IS THE ONE THAT GETS MISSED. §3.1(B): "promptly notify Cisco of Qualifying Downtime when You become aware of or reasonably suspect it. Notifications of Qualifying Downtime should be sent in writing to Cisco Duo Technical Support within 30 days from the time of Qualifying Downtime" — that clock runs from THE OUTAGE. §3.1(C) then requires the formal claim "via Cisco Duo Technical Support ticket no more than 30 days after the end of the applicable Measurement Period" — that clock runs from MONTH-END. An outage early in the month can therefore exhaust its notification window before the month it belongs to has even closed, so file the notice during the outage and the claim after month-end; do not wait for month-end to do both. ⚠️ DOWNTIME IS AN ERROR RATE, NOT WALL CLOCK: "Total Qualifying Downtime" is the aggregate minutes "during a Measurement Period (rounded upward to the nearest minute). 'Downtime' means when there is more than a five percent user error rate across all of a Customer's Users. Downtime is measured based on server side error rate." A long degradation sitting at a 4% error rate is contractually ZERO minutes, and the rate is measured ACROSS ALL of the customer's users — a failure confined to one region or one authentication method may never clear 5% organisation-wide. Build the claim on Duo's own reporting and offer our status-derived minutes as corroboration. ⚠️ AND THE CLOCK DOES NOT START WHEN THE SERVICE BREAKS: Qualifying Downtime "begins (i) when Cisco logs an incident ticket based on Cisco's identification of Core Services downtime, or (ii) upon Cisco's confirmation of Core Services downtime You report to Cisco; and ends when the Core Services are restored." The minutes before Cisco logs or confirms are not counted, which is a direct reason to report early rather than to report well. ELIGIBILITY: the customer must "be up to date on payment of all applicable fees" (§3.1(A)), and Cisco "reserves the right to deny the Service Credit if Cisco determines You are not eligible" (§3.3). Partner-sold customers may claim directly or have the Cisco Partner claim for them (§3.2). NO EVIDENCE IS REQUIRED: §3.3 makes supporting information optional — "If You have supporting information for Your claim that You want Cisco to consider, You should provide this information with Your claim." DUO FREE IS EXCLUDED OUTRIGHT (§4(F)). ⚠️ TWO TRAPS FOR WHOEVER REVISITS THIS. (1) "DuoCircle" (duocircle.com) is an UNRELATED third-party email-security vendor that publishes its own SLA; it is not Cisco Duo and its terms must never be read onto this row. (2) Duo's marketing blog announces a "99.99% uptime SLA for every customer" — directionally consistent with the document, but marketing, and no figure here came from it. §1's opening "Cisco will use commercially reasonable efforts to deliver the Cloud Service so that the Core Services meet or exceed the performance standards described in Table 1" is the DELIVERY obligation, not the remedy trigger: §2.1 pays "If Cisco fails to meet the Service Level for a given Measurement Period", which is indexed on the measured figure — so this is a genuine commitment and not a target, the same reading Miro's identical efforts qualifier got.