SLA Claim Deadlines: Track the 30- and 60-Day Windows Without a Spreadsheet

August 11, 2026

Every SLA credit has a shelf life, and it is shorter than you think. AWS wants your claim by the end of the second billing cycle after the incident, about 60 days. Azure gives you two months from the end of the billing month. Google Cloud gives most services 30 days from the end of the outage month, and DigitalOcean wants the request within 30 days of the billing cycle closing. None of these clocks start on the day of the outage, and none of them send a reminder. Miss the window and the SLA stops applying to the incident, with no appeals process in any of the four documents. This post lays out the exact windows from the current SLA pages and a tracking routine that takes ten minutes a month, no spreadsheet required.

The windows, straight from the SLA documents

Every provider counts the window from the end of the month or billing cycle, never from the incident itself. That single fact is why a spreadsheet column like "incident date plus 60 days" quietly fails: an incident on the 3rd and one on the 28th share the same filing deadline.

Two things worth internalizing. An outage on March 28 buys you no extra time over one on March 3: both windows close when the month does. And Google Cloud's window is the trap of the four. Its SLAs count from "the time Customer becomes eligible", which for a calendar-month calculation is the end of the outage month. Cloud Storage, BigQuery and Cloud NAT still say 30 days, while Compute Engine's SLA, revised in March 2025, says 60. Open the SLA page for the exact service and read its request clause before you file.

DigitalOcean is the same shape but split per product. Spaces and Container Registry: 30 days. Droplets: the end of the second billing cycle after the failure. Volumes and Kubernetes: within three months of the end of the cycle. And Spaces carries the meanest clause of the four providers: you must notify DigitalOcean in writing within 24 hours of downtime starting, or the credit is forfeited no matter how public the outage was.

The deadline is only the middle clock

Filing inside the window is one clock, but two others run on every claim. The first is noticing: if you never find out an incident hit your footprint, the deadline is irrelevant. The second runs after you file. AWS issues a confirmed credit within one billing cycle following the month your request is confirmed. Google applies credits within 60 days of the request. DigitalOcean Spaces credits expire 90 days after they are issued, so an approved credit that nobody applies can still vanish.

Track all three stages: when you noticed, when you filed, and whether the credit actually showed up on a bill. The claim is not done when you click submit.

Every provider counts the window from the end of the month or billing cycle, not from the day of the outage. An incident on March 3 and one on March 28 share the same filing deadline. Write the deadline on a calendar the day you see the incident, dated from month end, not from the incident.

Ten minutes a month: a deadline routine that works

The system is a fixed monthly audit, not a dashboard you check when you remember. Pick the 1st or 2nd of the month and do four things.

1. Pull last month's incidents: the AWS Health dashboard, Azure Service Health history, Google Cloud Service Health, the DigitalOcean status page, plus your own monitoring.
2. For each incident that touched your account, open the SLA page for that exact service and note its window. Windows differ inside a provider, not just between them, so never trust a single global number.
3. Put the filing deadline on a calendar as a dated event with a 3-day and a 1-day reminder. Compute it as month end plus the window, per the table above.
4. File anything still open, then log the status and check it off only when the credit appears on an invoice.

One row per incident keeps it honest:

What happens when you miss the window

Each SLA says it out loud. Google: failure to request in time "will forfeit Customer's right to receive a Financial Credit". DigitalOcean: failure to give notice "will forfeit the right to receive Service Credits". AWS: a late or incomplete request is not eligible, and the SLA calls itself the "sole and exclusive remedy". Azure requires the claim inside the two-month window, full stop. None of the four documents describes an appeals path for a late claim. The calendar is not bureaucracy; it is the mechanism that decides whether the credit exists.

The part the calendar cannot fix

Deadlines only matter for incidents you know about, and provider status pages do not email you that an incident touched your specific services. The reason most companies never claim is not laziness. Nobody told them an incident happened. That noticing gap is what UptimeAudit exists for: it watches the status and health feeds of AWS, Azure, Google Cloud and DigitalOcean down to the service and region level, and when an incident crosses an SLA threshold it drafts the claim with the deadline attached, so the calendar step is already done. You still review and submit, and the provider still decides.

Here is the move for this month. Open your provider's health dashboard, find the incidents from last month that touched your account, and for each one write the filing deadline on a calendar dated from the end of that month, not from the incident. File anything still inside its window before you close the tab. The credit is already sitting in the month's charges. The deadline is the only thing between it and your bill.