An SLA Credit Is Not Compensation for Downtime: Reading the Two Tables That Decide It

A service level agreement credit is not compensation for downtime. It is a refund of a slice of a bill you already paid, for service you did not receive, and the slice is smaller than almost anyone assumes when they read the word "guarantee" on a pricing page.

This matters because the two numbers that appear in the same paragraph of a contract — the availability commitment and the credit percentage — are not commensurate. The commitment is measured in minutes. The credit is measured in percent of invoice. Nothing in either number references what the outage cost you: the lost orders, the support queue, the customer who moved to a competitor at 3 a.m. The credit table caps out at refunding the money you spent on the thing that broke. It never approaches the money you lost because it broke.

That is not a criticism of any particular provider. It is what the instrument is. Every major cloud publishes a credit schedule that works this way, and understanding the shape of that schedule is a procurement skill, not a complaint. The rest of this piece is the arithmetic, the claim mechanics, and the design decisions that follow from both.

An SLA Credit Is a Refund Against a Future Invoice

The first thing to get straight is who holds the money while the argument is happening. On the compute SLAs that govern virtual machines, a credit is defined as a percentage of the monthly bill for the affected service in the region that missed its target. It is not cash. It is not a payment. It is an adjustment applied to an invoice that has not been issued yet.

The precise language is worth reading once. The Amazon Compute SLA states that service credits "will not entitle you to any refund or other payment," that they are applied "only against future payments," and that a credit is issued only if the credit amount for the billing cycle exceeds one dollar. The Google Compute Engine SLA is structurally identical: financial credits are a monetary credit applied to future use of the covered service, applied within 60 days after the credit was requested, and the maximum aggregate credit in a single billing month will not exceed the amount you owed for the covered services that missed the target.

Two consequences follow directly from that wording, and both are easy to miss.

First, the credit's ceiling is the invoice for the broken component. If a database host went down and your front-end fleet stayed up, the credit is computed against the database host's bill — not against the platform bill, and certainly not against revenue. The Google SLA makes the per-scope restriction explicit by stating that a customer is entitled to a credit for downtime of a particular VM instance either as a single instance or as instances in multiple zones, but not both. You do not get to claim the same outage at two levels.

Second, the credit is denominated in the currency of the thing you rented, which is usually the smallest line on the invoice. A compute instance is frequently the cheapest part of a workload: storage, egress, managed services, licensing and support contracts often exceed it. Refunding 30 percent of the compute line can be a rounding error against the total.

Two Tables Decide the Outcome, and Most Buyers Are Sitting in the Weaker One

The second thing to understand is that these SLAs are not one commitment. They are two, and they differ by more than an order of magnitude in the amount of downtime required to breach them.

The Amazon Compute SLA splits into a Region-Level SLA and an Instance-Level SLA. The Region-Level SLA covers EC2 with all running instances deployed concurrently across two or more availability zones in the same region, and commits to 99.99 percent. The Instance-Level SLA covers each individual EC2 instance and commits to 99.5 percent. Both use the same credit bands. The Google Compute Engine SLA splits along comparable lines, with multi-zone instances at 99.99 percent on the Premium network tier and a single instance of most families at 99.9 percent.

Read those two lines next to each other and the procurement implication is immediate. The number a provider quotes in marketing — 99.99 — is usually the multi-zone number. The number that governs the single VM you actually deployed is 99.5 or 99.9. Nobody is lying; the tiers are published. But a buyer who deploys one instance into one zone and files it mentally under "99.99 percent SLA" has imported a commitment that does not apply to their deployment.

Note also the third row. On Google, a memory-optimized single instance sits at 99.95 percent rather than 99.9 — a distinction that exists because that instance class is the one people run databases on, and the SLA reflects the engineering. On Amazon there is no equivalent single-instance escalation; the Instance-Level commitment is 99.5 percent regardless of family. If you are sizing a database host on the strength of an availability number, which table it came from decides whether the number is 99.5, 99.9, 99.95 or 99.99.

Four Minutes of Downtime Enters the First Band; Seven Hours Stay In It

The credit bands are laid out in the contract as though the intervals were roughly symmetrical. They are not. Converted to minutes in a 30-day month, the exposure each band covers is wildly uneven, and the first band is both the easiest to enter and by far the widest.

A monthly uptime percentage is computed by subtracting from 100 percent the share of minutes in the month during which the service was in a state of unavailability. That means a 30-day month has 43,200 minutes available, and each tenth of a percentage point is 43.2 minutes. From there the bands fall out arithmetically.

Follow the first band down the table. An outage of four and a half minutes and an outage of seven hours land in the same credit tier on Amazon: ten percent. The provider's exposure to you is different by a factor of roughly 96, and the credit is identical. Cross the seven-hour line, into the second band, and the credit goes from 10 to 30 percent. To reach a full 100 percent credit on a single instance you must lose more than 36 hours of a 30-day month.

That last number is the one worth sitting with. A full-credit event on the published schedule means an entire work-week-plus of continuous unavailability. Anything that resolves in a shift is bounded by the first or second band.

The Credit Is Priced Against the Invoice, and the Outage Is Priced Against Revenue

Now put a real bill underneath the percentages. The 16 vCPU / 32 GB tier of an hourly-billed instance at the observed rate of $0.49 per instance-hour costs $357.70 for a 730-hour month. A 30 percent credit on that line is $107.31. A 10 percent credit is $35.77.

Set that against what the industry reports about the other side of the ledger. ITIC's hourly cost of downtime research has for years put the cost of one hour of unplanned downtime above $300,000 for the overwhelming majority of surveyed firms, with a large minority reporting hourly figures in the seven-figure range. That research is not new — the report cited here dates from 2024 — so treat it as an order of magnitude rather than a current measurement. The order of magnitude is the point: a 36-hour full-credit event on a $357.70 line returns $357.70 against a loss measured in the millions.

Divide the credit by the outage to see the exchange rate directly. Sixty minutes of downtime on a $500 bill earns a $50 credit: 83 cents of relief per minute of outage. Four hundred and twenty minutes earns the same $50: 12 cents per minute. Eight hours crossing into the 30 percent band earns $150, or 31 cents per minute. Thirty-six hours earning $150 works out to 7 cents per minute. The longer and worse the outage, the less each additional minute of it is worth to you, because the credit steps in discrete jumps while the damage accrues linearly.

Five Ways a Serious Outage Fails to Qualify

The arithmetic above assumes the outage counts. Frequently it does not, and the disqualifying mechanisms are not exotic — they are the ordinary clauses at the bottom of the page.

One: the failure was not of the kind that is measured. Both SLAs define downtime narrowly. On Google, downtime for a VM means loss of external connectivity or persistent disk access. A VM that is reachable but running at a fraction of its throughput is not down. An instance whose storage is so slow that your application times out is not down. Latency, packet loss, degraded IOPS and intermittent partial failure all sit outside the metric, which means the incidents most likely to damage an application are the incidents least likely to generate a credit.

Two: the minutes were too short to count. The Google SLA states that partial minutes or intermittent downtime for a period of less than one minute will not count towards any downtime period. A failure mode that produces fifty-nine seconds of unavailability every few minutes for an hour is, by the metric, invisible.

Three: the cause is attributed to you or to conditions outside reasonable control. The Amazon exclusions disqualify unavailability caused by factors outside reasonable control, by your own actions or failure to respond to resource health concerns, by your equipment or software, or arising from a suspension under the agreement. The Google exclusions disqualify errors from your software or hardware, from third-party software or hardware, from behaviour that violates the agreement, or from quotas applied by the system. Read together, the two lists cover a large share of real-world incidents: your misconfiguration, a dependency you wrote, a quota you hit, a network problem beyond the provider's demarcation point.

Four: the correct scope was claimed, and the other one is now closed. Because a single instance cannot be claimed both as a single instance and as part of a multi-zone deployment, an unclear claim scope can cost the claim. The Amazon SLA is explicit that claims under the two levels cannot be combined or stacked for a particular instance.

Five: the evidence was not retained. Both providers require logs. Amazon requires request logs documenting the errors and corroborating the claimed outage; Google requires log files showing the downtime periods and the date and time they occurred. If your monitoring retains twenty-four hours of high-resolution data and the incident was eight days ago, the claim fails on documentation rather than on merit.

The Claim Window Expires, and It Expires Quietly

Every credit is opt-in, and every opt-in has a deadline that is stated in billing cycles rather than in days — which is precisely the unit most teams are not tracking.

Amazon requires the claim to be received by the end of the second billing cycle after the incident, submitted by opening a case in the support centre, with a specified subject line, the dates and times and affected region, the resource IDs, and the corroborating logs. Google requires notification within 60 days from the time you become eligible, with log files, and states plainly that failure to comply forfeits the right to the credit. Both apply credits to future use rather than issuing a payment, and AWS adds a one-dollar floor below which no credit is issued at all.

The operational conclusion is that a credit is an accounts-payable workflow, not an incident-response outcome. The teams that actually collect are the ones whose monitoring writes an immutable record of unavailability with timestamps, keeps it longer than the claim window, and has a named owner who calendars the deadline when an incident closes. Absent that, the credit is not merely reduced — it is forfeited, and the forfeiture is silent.

The One Clause That Is More Generous Than the Whole Table

Buried under the Amazon Instance-Level schedule is a rule that outruns the credit table by an order of magnitude, and it is worth reading in full because it points at how these instruments should be judged.

The SLA states that in addition to the Instance-Level commitment, no charge applies to any single EC2 instance that is unavailable for more than six minutes of a clock hour, that this applies automatically, and that no credit request is needed for any such hour. Six minutes is ten percent of an hour. So an hour in which an instance is down for seven minutes is not charged at all.

Compare what the monthly table would have given for the same twelve hours of accumulated downtime: the monthly uptime lands near 99.97 percent, the credit is ten percent of the month. The per-hour rule returns 100 percent of every affected hour, without a claim, without logs, without a deadline. It is bounded in a way the monthly table is not — it only covers the hours in which the instance was actually unavailable — but within those hours it is exact rather than aggregate.

This is the shape of a well-designed availability instrument: it measures the thing the customer experienced, in the unit the customer was billed in, and it applies itself. The monthly percentage tables are coarser by construction. That is not a reason to ignore them; it is a reason to know which one is doing the work when you estimate exposure.

Design Reduces Exposure More Than Any Credit Table

If the credit is a refund measured in the wrong unit, the rational response is not to litigate the unit. It is to reduce the number of minutes that qualify. That is a design decision, and it is measurable.

Research published by the Uptime Institute on 14 October 2026, combining its 2025 and 2026 annual data centre surveys into a sample of more than 1,200 respondents, quantifies the relationship between redundancy and outage incidence. For cooling, the proportion of respondents reporting at least one impactful outage in the past three years rose from 39 percent among those running 2N configurations to 70 percent among those running N. For power, the same curve ran from 42 percent to 68 percent. Serious outages — categories 3 through 5, which carry meaningful financial impact — accounted for roughly 8 to 11 percent of respondents with 2N configurations against approximately 19 to 22 percent of those running N.

The report also gives the relative reduction in the likelihood of at least one financially impactful outage over three years. Moving off an N baseline, the reduction was about 36 percent for N+1 cooling, 53 percent for N+2 and 63 percent for 2N; for power, about 23 percent, 37 percent and 44 percent. Measured instead against the more realistic N+1 baseline, 2N cooling was 42 percent less likely to have an outage and N+2 26 percent less likely. And the report notes that power and cooling together account for more than two-thirds of reported impactful outages in the 2026 survey.

Two caveats the authors state themselves, and both matter. Correlation is not causation: the analysis cannot separate redundancy from the operational maturity, maintenance practice and equipment condition that tend to accompany a well-built facility. And the figures are indicative reference points, not predictions for an individual site.

What the numbers do establish is the direction of the trade. Redundancy in the physical layer moves the probability of a serious outage by tens of percent. The credit table moves the recovery of your spend by 10, 25, 30 or 100 percent of a partial invoice, conditional on a claim. One of these instruments is aimed at the loss; the other is aimed at the bill.

Most Outages Are Short, Which Is Exactly When the Table Pays Nothing

Cloudflare's review of internet disruptions in the third quarter of 2026, published on 29 October 2026, provides a useful distribution of event durations from a network that carries more than 20 percent of web traffic across more than 330 cities. Radar recorded 49 disruption events in the quarter. Government-directed shutdowns accounted for 19, power outages 14 across 10 countries, and natural disasters five. Of the total, 14 events saw traffic return to typical levels in under an hour, and 16 recovered in less than three hours.

Read that alongside the band table and the interaction is unwelcome. A large share of real disruptions resolve inside three hours. Three hours is 180 minutes, which against a monthly commitment of 99.9 percent is roughly four times the entire monthly downtime budget — and yet, per the earlier arithmetic, it lands squarely inside the first credit band at 10 percent. The incidents frequent enough to plan for are the incidents the credit schedule prices lowest.

The quarter's most instructive single event was in Honduras on 10 September 2026. A power failure at an interconnection facility affected at least 11 major providers, and national HTTP traffic fell by 63 percent for about three hours. Eleven providers went down together because they shared a physical location. That is the structure of inherited risk: your provider's redundancy margin is not the only input, because the facility where your provider exchanges traffic is itself a failure domain, and it is shared by everyone else who chose the same point.

What to Do Instead of Counting on the Credit

Six steps, in the order that costs the least to act on.

Find out which SLA table governs each production instance today. Not the marketing number — the tier. An instance in one zone on the Instance-Level commitment is a 99.5 percent asset, and that single fact changes the downtime budget from 4.3 minutes a month to 3.6 hours a month. Write the tier next to the instance in the inventory.

Convert the commitment into minutes and put it on the dashboard. A percentage is inert; a minute budget is actionable. At 99.9 percent you have 43.2 minutes a month, 8.64 hours a year. At 99.5 percent you have 3.6 hours a month, 43.2 hours a year. Teams rarely realize how much budget the weaker tier hands them until they see the annual figure.

Instrument for evidence, not just for alerting. The credit requires logs with timestamps covering the unavailability window, retained past the claim deadline. That is a different retention policy from the one most monitoring stacks ship with by default, and it is the single cheapest change on this list.

Separate the failure domains you control from the ones you inherit. The Honduras event is the pattern to look for: several providers sharing one exchange or one facility. Ask which of your dependencies resolve to the same physical point. Where the answer is "all of them", you have a single point of failure that no SLA table can price, because when it fails, every provider on the claim list fails simultaneously.

Calendar the claim window at incident close, not at quarter end. Two billing cycles or 60 days is short enough that a busy week loses the claim. Make filing part of the incident checklist while the logs are still hot.

Price the design, then compare it to the credit. If the annual credit you can realistically collect on a given workload is a few hundred dollars, the decision to spread that workload across zones is not a billing decision — it is a decision about 43 hours of annual downtime budget versus 86 minutes, and the credit table will not make it for you.

A Worksheet for Your Own Exposure

Five measurements, all obtainable from records you already have. The output is a single number: the annual credit you can credibly expect, next to the annual downtime budget the commitment grants you. The gap between the two numbers is the argument for designing around failure rather than claiming after it.

Run that against a typical single-zone deployment and the shape of the problem becomes concrete. The commitment is 99.5 percent, so the budget is 3.6 hours a month. The affected service line might be a few hundred dollars a month. Twelve months of the observed incident pattern might produce two or three qualifying events, each resolving well inside the first band, each worth a ten percent credit. The annual number is small enough to be embarrassing next to the hours of downtime the commitment permitted — and that comparison, not the credit itself, is the useful output of the exercise.

For related arithmetic on how usage patterns turn into invoices, the October 2026 cloud server price benchmark breaks sticker rates into comparable units, and the analysis of how a peak-to-average ratio becomes the real bill shows why the shape of load, not its volume, drives the total. The terms that decide what leaving a provider costs are worth reading before signing anything that fixes a region or a configuration in place, and the comparison of which workloads actually save money on hourly billing covers the case where a machine is idle for most of the month.

Where Hourly Pricing Changes the Arithmetic

Everything above assumes the bill accrues whether or not the service is usable. That assumption is what an hourly-metered instance breaks.

SurferCloud prices its elastic compute by the instance-hour, with the observed rate card running from $0.05 per hour at 2 vCPU / 2 GB through $0.07, $0.13 at 4 vCPU / 8 GB, $0.25 at 8 vCPU / 16 GB, and $0.49 at 16 vCPU / 32 GB. All five tiers carry a bandwidth range of 1 to 10,000 Mbps, unmetered traffic, dedicated CPU and dedicated bandwidth. By the hour, that 16 vCPU / 32 GB tier is 49 cents; recomputed across a 730-hour month it is $357.70.

Why the unit matters for the subject of this article is the granularity of the meter. A monthly commitment prices the month. A credit computed against a monthly invoice resolves to a percentage of thirty days, which is why eight hours of downtime and seven hours of downtime return the same ten percent. An hourly meter prices the hour, which is the same unit the Amazon per-clock-hour rule uses when it waives the charge for any hour in which an instance was unavailable for more than six minutes. When the meter and the remedy share a unit, the remedy stops being an aggregate estimate of your loss and becomes an accounting of the hours you did not receive.

The practical effect is on idle time and on partial months. A workload that runs for a scheduled window, a test environment that exists for three days, a migration target that is provisioned, exercised and torn down — these are billed for the hours they existed, and they stop accruing when they stop existing. That does not make a credit larger; it makes the invoice smaller, which is the same outcome achieved one step earlier. The rate card is published on the hourly plan page at https://www.surfercloud.com/promos/hourlyvps, and the page is explicit that hourly billing is not discounted and that monthly deals carry the savings — a limitation worth stating plainly, because it decides which side of the trade a steady-state workload belongs on.

Two constraints on the same page are also worth planning around rather than discovering later. All plans use data centre IPs with no replacement option, and port 25 is blocked by default. The system disk is free up to 40 GB, except at São Paulo and Dubai, where it is 20 GB. Default usernames vary by image: administrator on Windows, root on CentOS, Debian and RedHat, ubuntu on Ubuntu. None of these affect the SLA arithmetic, but all of them affect whether a migration lands cleanly inside a maintenance window, which is the same problem in a different costume.

FAQ

Is an SLA credit the same as compensation for downtime?

No. It is a percentage of the bill for the affected service, applied against future invoices. It is capped at the amount you paid for the component that failed, and it is calculated without reference to what the outage cost you.

If the provider promises 99.99 percent, am I covered at 99.99 percent?

Only if your deployment matches the scope that commitment describes. On Amazon that means instances deployed concurrently across two or more availability zones; a single instance falls under the 99.5 percent Instance-Level commitment. On Google, multi-zone instances on the Premium tier sit at 99.99 percent while a single instance of most families sits at 99.9 percent.

How long an outage does it take to get a full credit?

On the published tables, more than 95 percent availability. In a 30-day month that is more than 36 hours of downtime for a single instance — roughly a working week and a half of continuous unavailability.

Do I have to file a claim?

Yes. Both the Amazon and Google compute SLAs require the customer to request the credit inside a fixed window — the end of the second billing cycle, and 60 days, respectively — and to supply logs corroborating the outage. The Amazon per-clock-hour waiver is the exception; it applies automatically.

Will the credit cover my actual loss?

It will not come close. The credit is denominated in the affected service's monthly bill. The loss is denominated in revenue, support load and customer retention. The instruments operate in different currencies and no reconciliation is provided between them.

What reduces exposure more, redundancy or a better SLA?

Redundancy, because it reduces the minutes that qualify. The Uptime Institute's October 2026 analysis associates moving from N+1 to 2N cooling with a 42 percent lower likelihood of a financially impactful outage, while the credit schedule changes by ten or twenty percentage points of a partial invoice, conditional on a documented claim.

The Short Version

An availability commitment and a credit table are two different documents stapled together. The first describes how much downtime the provider expects to be blamed for. The second describes how little of the invoice it will return when blame is established. Four and a half minutes of downtime and seven hours of downtime pay the same ten percent, and a full credit requires more than 36 hours of a single instance being unreachable.

The productive response is to stop treating the credit as the remedy and start treating it as a diagnostic of the wrong metric. Read which tier governs each production instance, convert the commitment to minutes, retain logs long enough to file, find the physical points your dependencies share, and price the design that reduces qualifying minutes rather than the claim that compensates for them.

Where the workload's demand is intermittent, metering it by the hour keeps the invoice aligned with the hours the machine actually existed — the same alignment between meter and remedy that the more generous SLA clauses achieve. The rate card, the constraints and the region list are published in one place at the SurferCloud hourly cloud server page, alongside the note that hourly billing is not discounted and monthly deals carry the savings. A related checklist for multi-region SLA compliance covers the governance side, and both are worth thirty minutes before the next renewal rather than after the next incident.