Fill vendor, period, promised uptime, downtime, and evidence → structured claim text you can copy or download.
Cloud and SaaS contracts often promise uptime (for example 99.9% monthly) and define tiered service credits when measured availability falls short. Filing a claim is rarely automatic — you must show the vendor that qualifying downtime exceeded the allowed budget for the measurement period, using their definitions and deadlines.
A strong claim pack is factual, timestamped, and tied to contract language. This generator assembles those facts into one document you can paste into a support ticket or email. It does not submit on your behalf, guarantee approval, or interpret legal terms.
Support engineers process dozens of vague messages (“site was down about an hour”). A pack with promised %, achieved %, minute totals, and evidence links is faster to route to the SLA team. Even when rejected, you get clearer reasons — which feeds your next contract negotiation.
period_minutes = period_days × 24 × 60
allowed_downtime = period_minutes × (1 − promised_uptime / 100)
achieved_uptime % = 100 × (1 − qualifying_downtime_minutes / period_minutes)
Match period length to the contract — calendar months vary (28–31 days). Use our Allowed Downtime Calculator to cross-check the budget and calendar month SLA tables for common targets.
Vendor: Hypothetical Cloud Co. · Promise: 99.9% · Period: March (31 days).
Period minutes = 31 × 24 × 60 = 44,640. Allowed downtime = 44,640 × 0.001 ≈ 44.6 minutes.
Qualifying downtime logged: 72 minutes (two incidents, UTC timestamps in evidence).
Achieved = 100 × (1 − 72/44,640) ≈ 99.839% — below 99.9%.
Next step: quote credit tier from contract (e.g. 10% of monthly fees for 99.0–99.9% band) via SLA Penalty Calculator.
Reported downtime: 90 minutes. Contract: 60 minutes were pre-approved maintenance with ticket #M-4421.
Qualifying downtime for SLA = 90 − 60 = 30 minutes only.
Lesson: always subtract excluded windows before generating the pack. Vendors will reject otherwise.
Monthly cloud bill: $8,000. Credit tier yields 10% = $800.
Internal downtime cost estimate (checkout down 72 min at $12k/hour peak): ≈ $14,400 revenue at risk.
File the credit anyway — but present leadership both numbers so nobody confuses vendor compensation with full impact.
Before filing, re-read: definition of “Unavailable,” excluded maintenance windows, force majeure, credit caps (often 30–100% of monthly fees maximum), sole remedy clauses, and dispute deadlines. Some contracts credit only if you file within 30 days of month-end; others within 30 days of incident. Missing deadline is the most common self-inflicted rejection.
Some cloud SLAs apply per-region or per-service SKU. A US-East failure may not credit if your contract measures global availability. Conversely, a single-region customer may credit while global metrics look fine. Tag evidence with the region and product ID named in the agreement — not your internal codenames.
Finance cares about invoice credit amount and timing. Legal cares about whether claiming waives other remedies. Ops cares about whether the vendor root cause is fixed. Send the claim pack to finance with expected tier and dollar estimate; loop legal if contract has dispute clauses; do not close the internal incident until vendor RCA is acceptable or you accept residual risk.
Keep a spreadsheet of claims filed: vendor, period, minutes claimed, credit received, delta. Over years you learn which vendors honor monitors vs argue definitions — data for renewal negotiations beats anger.
When credit is a small fraction of business loss, leadership may ask “why bother?” Answer: credits fund the reliability budget; they set precedent with vendors; and the discipline of filing forces accurate uptime measurement you should be doing anyway for customer SLAs.
Day 0 incident end → Day 1 internal minutes tally → Day 3 claim pack to account team → Day 14 vendor acknowledgment → Day 30 credit on invoice or dispute letter. Mark calendar deadlines from contract the day after incident — not when finance remembers month-end.
After achieved uptime is below promise, map to contract table. Example tier structure (always read your contract): 99.0–99.9% → 10% monthly fee credit; 95.0–99.0% → 25%; below 95% → 50% cap. On $8,000 monthly bill with achieved 99.839% (example from March breach), 10% tier → $800 credit. Compare to internal loss via Downtime Cost — credits rarely match business impact.
Monthly fee: $12,400 · Promise: 99.95% · Achieved: 99.91% (28 min downtime in 30-day period of 43,200 min).
Contract tier: 99.9–99.95% → 10% credit = $1,240.
Internal downtime cost estimate: 28 min at $18k/hr ≈ $8,400 revenue at risk. File $1,240 credit; present $8,400 impact to leadership separately.
This generator formats text from your inputs. It does not parse PDF contracts, submit portals, guarantee approval, or provide legal advice. Vendor definitions of downtime, exclusions, and caps always override calculator math — human review required.
Whether approved or denied, attach vendor response to internal post-mortem. Denied claims often reveal monitoring gaps — “your evidence excluded maintenance we logged” means fix tagging in observability. Approved credits should flow to finance with ticket ID; ops should still track root cause fix separately — $800 credit does not replace fixing flaky region failover.
Hyperscalers often publish their own status history — cite vendor status page URL with UTC acknowledgment time even when your monitors disagree on minutes. Discrepancies go to dispute letter with both datasets. Include account ID, region, and service SKU exactly as contract defines — internal project names cause routing delays.
Credit estimate: SLA Penalty Calculator · Business impact: Downtime Cost · How to file: SLA service credit claim guide · Post-incident write-up: Post-Mortem Generator · Hub: Reliability Money Toolkit · Free Tools.
Vendor identity, contract or account ID, measurement period, promised uptime, total qualifying downtime with UTC timestamps, achieved uptime calculation, monitoring evidence, and the credit tier you believe applies per contract language.
achieved% = 100 × (1 − downtime_minutes / period_minutes). Period minutes = days × 24 × 60. Use the same period definition as your vendor agreement.
No. It produces structured text you copy into email or a support portal. You still submit through the vendor's official process and meet their deadline.
Common reasons: excluded downtime, insufficient evidence, wrong measurement period, missing UTC timestamps, or filing after the allowed window.
Almost never. Credits are usually a percentage of fees for the period, capped in the contract. Business loss from revenue or churn can be much larger.
Use both when possible. Independent monitors show customer-observable failure; vendor status pages show what they acknowledged. Align timestamps in UTC.
No. Contracts define downtime, exclusions, credit caps, and dispute processes. This tool organizes facts; legal or procurement interprets enforceability.
When achieved uptime still meets the promise, when downtime is clearly excluded, when the credit is below your internal threshold, or when relationship cost outweighs a small credit — but document the decision.