Maintenance Windows and SLA Credits: Where AWS, Azure, GCP, and DigitalOcean Draw the Line
August 25, 2026
Your provider emails that a maintenance window starts at 02:00. At 02:04 your instance stops answering, and at 02:18 it is back. Real downtime for you, real money on your bill, and under most SLAs it is not an outage at all. Whether you can claim it comes down to one thing: the notice you were given. The four big clouds draw that line in four different places, and one of them recently moved it.
The short answer
Each provider treats maintenance differently in its SLA, and the differences decide whether the same outage is worth a claim or a shrug.
| Provider | Scheduled maintenance excluded? | Condition | Claim deadline |
|---|---|---|---|
| AWS (EC2) | Not in the current text | Old SLA excluded it; the May 2022 rewrite dropped the clause | End of the second billing cycle after the incident |
| Azure (VMs) | Yes | Only if Microsoft notified you at least 5 days before | Within 60 days of the incident |
| Google Cloud (Compute Engine) | No | Not listed among the SLA exclusions | Within 60 days of eligibility, with log files |
| DigitalOcean (Droplets) | Yes | No notice requirement stated in the SLA | Within 2 billing cycles |
Notice is the dividing line
Maintenance windows are not magic. They remove downtime from the uptime math only when the provider's own SLA defines them, and only when the provider tells you about them in advance. The word that does the work is "scheduled", and providers define it by the notice they give, not by whether their own team planned it. A change rolled out with no warning is an ordinary outage to your contract, whatever it was called internally.
The dividing line is notice. Providers exclude the maintenance they told you about, not the maintenance they did not. No advance warning means the downtime was never scheduled from your side of the agreement, and it counts against the SLA like any other outage.
This is where most people lose the money: "maintenance window" makes them stop reading. The window is only excluded if it was announced on the terms the SLA sets; everything else is claimable.
AWS: the exclusion that quietly disappeared
Amazon rewrote its EC2 SLA into the Amazon Compute SLA, published May 25, 2022. The older versions were explicit about maintenance: the exclusions that ran through 2020 and 2019 carved out downtime that "result from any maintenance as provided for pursuant to the AWS Agreement". The rewrite dropped that sentence. The exclusions today are factors outside AWS's control, your actions or inactions, your equipment and software, and suspension of your account. Maintenance is not on the list.
The practical reading: if an EC2 maintenance event takes a single instance out of connectivity, that is Unavailability under the Instance-Level SLA's 99.5% target, and maintenance no longer gets a free pass. A region-wide event that drops all your instances across two AZs touches the Region-Level SLA at 99.99%. AWS even gives you one credit you do not have to ask for: any single instance unavailable for more than six minutes of a clock hour is not billed for that hour.
The caveat: the current SLA keeps a sentence that lets AWS issue a credit "at our discretion" when availability is affected by factors outside its calculation, so support still makes the call on borderline claims. File through a support case with "SLA Credit Request" in the subject, attach the logs that document the errors, and get it in by the end of the second billing cycle after the incident. Individual credits under $1 are not paid.
The same 90 minutes, on paper
Run the numbers once and maintenance stops being abstract. Take a single running machine on a $5,000 monthly bill and an outage of 90 minutes in a 30-day month. Uptime lands at 99.79%.
| Deployment | Monthly target | 99.79% vs target | Credit on a $5,000 month |
|---|---|---|---|
| AWS EC2, single instance | 99.5% | no breach | $0 |
| AWS EC2, two availability zones | 99.99% | breach | $500 |
| Azure VM, single, Premium SSD | 99.9% | breach | $500 |
| Google Compute Engine, single instance | 99.9% | breach | $500 |
| DigitalOcean Droplet | 99.99% | breach | up to $5,000 |
Drop the same 90 minutes inside an announced window and DigitalOcean's row falls to $0, Azure keeps its $500 only if Microsoft skipped the five-day notice, and AWS keeps the multi-AZ $500 unless support reaches for a leftover exclusion. The notice decides who takes it home.
Azure: five days of notice is the whole contract
Microsoft's consolidated SLA defines Scheduled Downtime as downtime from network, hardware, or Service maintenance or upgrades, and requires Microsoft to notify you at least five days before it starts. Downtime does not include Scheduled Downtime. The notice is the contract: a window announced five days out is out of the uptime math; a change that breaks a VM with 48 hours of notice is not scheduled, and it counts.
Two more exclusions sit nearby. Microsoft's general limitations remove a "monthly maintenance window that incurs a downtime to patch your server and infrastructure" from the uptime calculation, which is how customer-set patch windows on database and PaaS services drop out. And your own operations are excluded: restart, stop, fail over, scale. Reboot a VM into an outage and it lands on your side of the ledger.
Live migration covers more than 90% of Azure VMs, and a no-reboot pause is under 10 seconds, rarely around 30, and no more than once every 18 months. Hardware decommissioning gives you a self-service window of about 14 days, host maintenance about 35, and the catch is the word "unless urgent". Urgent work skips the long notice, so when it takes a VM down without the five-day heads up, it is not Scheduled Downtime. The path is open: Help and support, New support request, Billing, Refund Request, within 60 days. For metered services like VMs, the credit base is the fees for the 30 days before the incident.
Google Cloud: no maintenance clause at all
Google's Compute Engine SLA, last touched in March 2025, lists exclusions for pre-general-availability features, documented feature exclusions, force majeure, customer or third-party software and hardware, abusive use, and quotas. Maintenance is not there. Downtime is defined as loss of external connectivity or persistent disk access, and outages shorter than a minute do not count.
In practice Google absorbs most maintenance through live migration, so nothing counts against you. The exposed case is an instance that cannot live migrate, such as some GPU and specialized families, or one with host maintenance set to terminate: the machine stops and restarts, which is plain downtime against a 99.9% single-instance commitment (99.95% for memory-optimized). Google's exclusions do reach "errors that resulted from Customer's software or hardware", and a terminate-over-migrate setting is exactly the kind of thing they may point at. The path still exists: notify within 60 days of eligibility with logs showing the downtime periods, and expect the credit within 60 days, capped at the month's bill in the region.
DigitalOcean: maintenance is out, no notice needed
DigitalOcean's Droplet SLA lists scheduled maintenance and customer-initiated downtime as exclusions, and requires no notice for the exclusion to hold. Maintenance is maintenance. The sting is that DigitalOcean's payout is the most generous of the four where coverage applies: miss the 99.99% mark on a Droplet in a billing cycle and all of that Droplet's charges come back as credit. That same exclusion erases the biggest possible payout of the four, so be sure here that the outage really was announced. When it was not, file within two billing cycles by emailing success@digitalocean.com with the Droplet IDs and outage dates.
What to do at the next maintenance window
Check the notice before anything else. Was there a five-day heads up, a status page post, a health banner? A message two hours before the work starts is not scheduled notice under any of these agreements.
Log the outage as it happens, not as a story later: timestamps in UTC, instance and region identifiers, error counts from your own metrics. The full checklist is in What Counts as Evidence in an SLA Credit Claim.
File for anything unannounced. If you got no advance warning, the downtime was not scheduled at your level and it hits the uptime percentage like any other outage. Do not talk yourself out of the claim on the grounds that "it was maintenance".
Respect each clock: AWS wants the request by the end of the second billing cycle after the incident, Azure within 60 days, Google within 60 days of eligibility, DigitalOcean within two billing cycles. Put the filing date in your calendar, not in your memory.
If the last outage you swallowed happened inside a maintenance window, go back and check what they sent you in writing, and when. No notice means no exclusion. The claim was always yours to file; status-tracking tools like ours exist so the deadline is never the reason it dies. The provider still makes the final call.