Verification Checklist

  • ✓Check whether your API service agreement's SLA clause covers "availability / response time" only, or also generation content quality — don't conflate the two
  • ✓When a real outage or error spike happens, did you record the exact start/end time and error codes immediately, rather than relying on memory afterward
  • ✓Do you have your own logging pipeline (request timestamps, HTTP status codes, error messages) that can serve as independent evidence for a claim, instead of relying only on the vendor's status page
  • ✓Have you confirmed compensation requires an active claim within a filing window (e.g. within the calendar month or a set period after), rather than automatic compensation once the vendor detects the shortfall
  • ✓Have you verified the exact availability percentage, measurement period, and compensation ratio against the specific vendor's official SLA document, instead of assuming another product's numbers apply

1. The pattern: teams only ask about compensation after an outage already happened

Enterprises integrating DeepSeek or Qwen APIs into a product or internal tool rarely open the SLA (Service Level Agreement) clause in the service contract until the API actually starts timing out, throwing frequent 5xx errors, or becomes completely unreachable for a stretch of time. That's usually when the question "should we be compensated for this" comes up for the first time. Two things typically block a claim at that point: first, nobody is sure what the SLA actually promises or whether this specific outage even qualifies; second, even if someone wants to file a claim, there's no concrete evidence of exactly how long the service was actually down — just a vague "it wasn't working earlier," which rarely gets a substantive response from support.

2. What SLA actually covers: availability and latency, not output quality

To understand whether an outage qualifies for compensation, you first need to know what dimension the SLA clause actually promises. The SLA documents published by major domestic model vendors typically commit to "service availability" (whether the API responds normally within an agreed period, whether the error rate stays under a threshold) and "response time" (whether requests return within an agreed latency), both of which are purely technical metrics that can be objectively measured from call records. A common misunderstanding among developers is assuming that a model giving an unsatisfying, off-topic, or low-quality answer also counts as an SLA violation. But the SLA clause has never covered the quality or accuracy of the generated content itself — if the API returned a 200 status code within the promised latency, that call counts as "normal" under the SLA regardless of whether the answer content was any good. Availability is about whether the pipe works and how fast; generation quality is a separate capability question entirely, and service agreements usually carry a separate disclaimer stating they make no guarantee about the accuracy of generated content.

3. How compensation is calculated: a usage-proportional voucher, not cash

Once you've confirmed an outage actually falls under SLA-covered "availability shortfall," the next thing to check is what form the compensation takes. A common structure among domestic cloud vendors is to calculate an availability percentage over a measurement period (often a calendar month), then map that percentage into a tiered compensation ratio — compensation is typically issued as service credit or a voucher applied against future bills, not refunded as cash. It's worth stating plainly: the exact availability percentage promised, the length of the measurement period, and the tiered compensation ratios vary across vendors, and even across product lines or subscription tiers (e.g. personal vs. enterprise plans) from the same vendor. There is no single industry-wide standard here — the actual numbers must be verified against the official SLA document for the specific product you purchased, not borrowed from another product or vendor's published figures.

4. Vendors don't compensate proactively: you must file the claim yourself

Another easily overlooked reality: SLA compensation almost always requires the user to actively file a claim — the vendor's backend monitoring detecting a shortfall does not automatically credit your account. This means that if your team didn't notice the outage, or missed the filing window, the compensation you were objectively entitled to will most likely never land on your account. Claims typically must be submitted within a limited window (e.g. within the calendar month of the outage, or one to two months after that month ends); miss the deadline, and many vendors' rules treat the claim as forfeited by default. This is exactly why "knowing the SLA clause exists" and "actually receiving compensation" are separated by one more required step: actively filing the claim.

5. What evidence to keep so an SLA claim actually goes through

Rather than scrambling for evidence after an outage happens, it's more practical to treat call monitoring as ongoing baseline work. Specific recommendations: first, log every API call's request timestamp, returned HTTP status code, and specific error message (timeout, 5xx, rate-limit rejection) into your own logging system — don't rely solely on the vendor's status page, since how promptly and completely that page reflects the exact incident you experienced is itself uncertain. Second, the moment you notice a clear anomaly (a sudden spike in error rate, a burst of timeouts), proactively screenshot or export the monitoring dashboard and log snippets from that window, so you can later reconstruct the exact start and end time of the outage. Third, find the specific "how to file a claim" section in your vendor's official SLA document ahead of time — where to submit it and what the deadline is — so you're not scrambling to figure this out when it actually matters. Your own outage logs and timestamps are the most direct, persuasive evidence when it's time to file an SLA compensation claim.

6. Bottom line: SLA is an availability account, not a content-quality account

When enterprises buy DeepSeek or Qwen API access, the SLA clause in the contract covers service availability and response time — not the quality or accuracy of generated content. That's the first line to draw when deciding whether an outage even qualifies as an SLA violation. Compensation is typically a voucher proportional to service fees rather than cash, and the exact availability percentage, measurement period, and compensation ratio vary by vendor, product line, and subscription tier — there is no unified industry standard, and the official SLA document always governs. More importantly, compensation almost always requires an active claim with outage evidence filed within a deadline — vendors don't compensate proactively. Keeping your own outage logs and timestamps day-to-day is the actual prerequisite for turning an SLA promise into a real credit.