The percentage is the least important number in the contract
An availability promise consists of four pieces of information, and the percentage is the last of them. Before it come the measurement point, the reference period and the definition of what counts as an outage at all. If one of those three is missing, the contract holds a number but no procedure for recalculating it. The German law firm IT-Recht Kanzlei starts exactly there in its article on the service level agreement: the parties first have to define when the IT system is considered unavailable. (Quotations from German sources are translated; the verbatim wording is in the linked originals.)
That sounds obvious and rarely is. In most quotes the percentage is in bold and the rest is missing entirely. How percentages translate into minutes and hours is covered elsewhere: converting percentages into minutes has the table for that. This article starts one level earlier, with the question of whose measurement is the basis of the calculation in the first place.
- Measurement point - from which location, over which path and with which procedure the check runs.
- Reference period - month, quarter or year; the IT-Recht Kanzlei notes that the time units typically used are minutes, hours, days, months, quarters or years.
- Outage definition - which state counts as unavailability, and from which duration onwards.
- Percentage - the number that carries nothing without the three settings above it.
Keeping that order makes the negotiation shorter. The percentage is a matter of bargaining, the three settings above it are craft. Together they take up less than a page of contract text.
The measurement point: one website, four different numbers
Between the service in the data centre and the browser of the client there are several layers, and each of them can fail on its own: the application, the load balancer, the provider network, name resolution, the certificate, an upstream delivery network. A measurement point inside the data centre sees only the first layer. A measurement point outside sees what a visitor sees.
That is why the typical SLA dispute does not grow out of one wrong number but out of two correct ones. The provider measures internally and arrives at 99.98 percent, the client measures from outside and arrives at 99.62 percent. Both values are right within their own frame, but only one of them describes what the end customer experienced. Why a single measuring location is not enough for this is set out in why one location is not enough.
"Measured at the handover point" is not a definition for as long as the handover point is not named. The contract needs location, procedure and interval: which locations run the check, whether over HTTPS and with a full page render, at which spacing, and after how many consecutive failed attempts an outage starts. Two locations failing at the same time is a different statement from one.
On reporting, the IT-Recht Kanzlei goes one step further and names the trust problem openly: reports the provider writes about itself rest on trust. Its recommendation is unambiguous: reports should not be produced by the provider but by a third party, or generated from the system in a way that cannot be manipulated. An independent measuring point fills exactly that role. Uptime monitoring from several locations produces a number that neither contracting party creates on its own, which removes the starting point of the argument.
What counts as an outage decides half the number
A server that answers every request with status 200 counts as available in many contracts. That is the weakest definition imaginable. RFC 9110 puts the status code briefly: "The 200 (OK) status code indicates that the request has succeeded." It says nothing about the content of the response. An error page with status 200 meets the promise on paper and misses its purpose: pages that report 200 despite an error describes the pattern and its consequences.
A workable outage definition therefore stands on three legs: status code, content check and response time. For the hard case RFC 9110 is clear: "The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method." The soft case is the one the IT-Recht Kanzlei describes: a service can be available and still fall short of the quality the client expects or has agreed. That state can be measured too, but only if it was named beforehand.
Which codes count as success. Status 200 on its own is too little; redirects to an error page and the entire 5xx class need an explicit rule.
A string that is present on the working page and absent from the error page. Without it every maintenance page counts as a successful response.
From which response time an answer counts as an outage. Without a threshold a page that takes forty seconds is contractually available.
How many consecutive failed attempts from how many locations start an outage, and which event ends it again.
{
"measurement_points": ["fra", "hel", "ash"],
"interval_seconds": 60,
"success": {
"status": [200, 204],
"body_contains": "Basket",
"response_time_ms_max": 4000
},
"outage_starts_at": {
"failed_attempts": 2,
"locations_at_once": 2
},
"reference_period": "calendar_month",
"maintenance_windows": [
{ "day": "Sun", "from": "02:00", "to": "04:00", "zone": "Europe/Berlin", "max_hrs_month": 4 }
]
}Such a block is not a contract annex, but it shows how little text is needed to make a promise recalculable. Whether the full page render in a real browser is measured on top of the server response, or only the server response itself, is a deliberate decision: browser monitoring measures one, API monitoring the other. What matters is that the contract says which of the two is meant.
The check interval belongs in the same setting. A check every five minutes detects an outage after two and a half minutes on average and rounds it to that grid in the evaluation; a check every minute gives a finer curve and more data points. Check interval and detection time works through the relationship.
The reference period shifts the tolerance by days
The same percentage means something entirely different in different reference periods. According to the IT-Recht Kanzlei, the arithmetic runs like this: if 99 percent availability around the clock per month were agreed, then even in months with 31 days the system could be unavailable for at most 7.44 hours. On a yearly basis the ratio tips over: if the system has to be available around the clock across the whole year, which the firm puts at 8736 hours, then 99 percent availability per year means an acceptable outage of 87.36 hours.
Those 87.36 hours are more than three full days, and nothing in the contract forbids taking them in one go. The firm recommends accordingly that for high-availability systems it is advisable for the client to agree shorter reference periods. A monthly basis limits the individual damage, a yearly basis smooths it away.
- Monthly - a 99 percent promise allows 7.44 hours (IT-Recht Kanzlei); the individual incident stays visible in the billing.
- Quarterly - three times the tolerance; one bad month is carried by two good ones and credits are triggered less often.
- Yearly - the same promise allows 87.36 hours (IT-Recht Kanzlei); a three-day outage still adds up to a compliant year.
A provider who insists on the yearly basis also makes its own metric useless: an outage in January has statistically disappeared by December, but not from the memory of the client. Billing per month serves both interests better because it keeps the metric close to the event someone still remembers.
Maintenance windows: planned, capped, announced
Planned maintenance is not an outage if the contract says so. The IT-Recht Kanzlei points out that where high availability is agreed, the provider should make sure maintenance windows are taken into account in the availability measurement. The emphasis is on window: position, maximum duration and notice period belong in it. A clause that allows maintenance at any time and without limit hollows out the promise; section 307(1) sentence 2 of the German Civil Code makes clear that an unreasonable disadvantage may also arise from a provision not being clear and comprehensible.
Technically the window needs the matching status code. RFC 9110 describes this exact case: "The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay." How to implement that cleanly is in setting 503 and Retry-After correctly; why an agreed window also has to be stored in the measurement so it does not raise false alerts is in maintenance windows in monitoring.
First the position: weekly on Sundays between 02:00 and 04:00 Europe/Berlin. Second the cap: at most four hours per calendar month, every minute beyond that counts as an outage. Third the notice: announced at least 48 hours in advance in text form, for security-critical work without undue delay and with a report afterwards. With all three sentences in the contract, nobody argues later about whether a window was one.
Response time and restoration time are two deadlines
Besides availability, most SLAs contain two deadlines, and they are regularly mixed up. The IT-Recht Kanzlei separates them cleanly: the response time is the period within which the provider has to begin the fault-clearing work, while the restoration time is the period within which the provider has to complete that work successfully. A promise that names only one of the two leaves the other open.
Both deadlines need a starting point, otherwise they never begin to run. The same article states that it is always of material importance to agree when each period starts, for example with receipt of the fault report, and during which hours it runs. An automatic alert with a timestamp is worth more here than any later reconstruction from mail threads: alerts with a timestamp document receipt of the report without anyone having to remember to.
It also makes sense not to treat every fault alike. The firm recommends grading them and working with fault classes, agreeing a corresponding reduction in remuneration for priority II faults, where usability is impaired, and priority III faults, which are minor. A complete failure of the checkout and a slow image area are not the same event and do not need the same legal consequence.
The second line shows that a single node was down while the address as a whole still answered. Such calls do not replace a report, but in case of doubt they answer faster than any email whether a measurement happened at all and what exactly was measured. The timestamp in the third line belongs in the same note, otherwise the measurement cannot be placed a week later.
Service credits: contractual penalty or liquidated damages
If the promise is missed, a legal consequence follows. In practice it is called a service credit and in law it is almost always one of two things. The IT-Recht Kanzlei draws the line: a contractual penalty has to be distinguished from liquidated damages, which merely serve to ease the burden of proof and to keep proceedings efficient. The difference is not academic; it decides whether the clause holds and whether further damages can be claimed alongside it.
For the contractual penalty, section 339 sentence 1 of the German Civil Code applies: if the debtor promises the creditor payment of a sum of money as a penalty in the event that he fails to perform his obligation or fails to perform it properly, the penalty is forfeited when he is in default. On top of that comes a trap that regularly bites in running contracts. Section 341(3) provides that a creditor who accepts performance may demand the penalty only if he reserves the right to do so on acceptance. Paying the monthly invoice without reservation can cost the credit for that same month.
For liquidated damages in consumer business, section 309 no. 5 letter b of the German Civil Code applies: a lump sum is void if the other party to the contract is not expressly permitted to show that no loss or diminution in value has occurred at all, or that it is substantially lower than the lump sum. Between businesses that provision does not apply directly; section 310(1) sentence 1 exempts standard business terms used towards an entrepreneur, a legal person under public law or a special fund under public law from sections 308 no. 1, 2 to 9 and 309.
That is not the all-clear. The review of content under section 307 remains applicable in business dealings, and the contra proferentem rule applies in any case: under section 305c(2), doubts in the interpretation of standard business terms are resolved against the user of those terms. Whoever writes a clause carries its interpretation risk. In practice that means the more precise the outage definition, the smaller the risk in your own clause.
A third legal consequence is often overlooked in the negotiation. The IT-Recht Kanzlei names it explicitly: another possible sanction is termination of the SLA for good cause. For a client whose business depends on reachability, a special right of termination after several missed months is usually worth more than any credit.
The five percent cap and what 2024 added
For the amount there is a figure that has stood for more than twenty years. The IT-Recht Kanzlei sums it up: according to the case law of the Federal Court of Justice, contractual penalties in standard business terms are void if they exceed the cap of 5 percent of the contract value, citing the decision of 23 January 2003, VII ZR 210/01. The law firm GÖRG dates the same decision in its legal update of October 2024, noting that in 2003 the court held a contractual penalty of 5 percent of the contract sum to be just about permissible.
In February 2024 the Federal Court of Justice went further, and it did so at the reference figure. The legal update describes it as follows: by judgment of 15 February 2024, VII ZR 42/22, the court held that in a unit-price contract a contractual penalty of 5 percent tied to the originally agreed contract sum is void as standard terms of the client because it unreasonably disadvantages the contractor. The reasoning hits everyone who ties service credits to a planned figure: the limit of what is reasonable is exceeded and the clause is therefore void in its entirety.
Both decisions were handed down in construction contract law. The reasoning on the cap in standard business terms is drawn on beyond that field; the IT-Recht Kanzlei cites it expressly for IT contracts in its article on the service level agreement. For an SLA two things follow. First, the cap needs a reference figure that is still correct at the end, meaning the remuneration actually invoiced for the period concerned rather than the sum in the offer letter. Second, a clause drawn too widely is no smaller a problem than a missing one, because it falls away in full and statutory law remains. The legal update draws the practical conclusion that in the light of the decision, penalty clauses in existing contracts and in contract templates must be reviewed and, where necessary, adjusted.
| Wording in the contract | What stays open | Consequence in a dispute |
|---|---|---|
| Availability 99.9 percent | measurement point, reference period, outage term | interpretation; doubts are resolved against the user (section 305c(2) German Civil Code) |
| Measured at the data centre handover point | network path, name resolution, page render | the client experiences outages that never appear in the report |
| Reference period: calendar year | distribution of outages across the year | 99 percent allow 87.36 hours, even in one go (IT-Recht Kanzlei) |
| Maintenance possible at any time | position, maximum duration, notice period | clause without a time limit; the yardstick is section 307(1) German Civil Code |
| Service credit 10 percent of the annual fee | reference figure and cap | above 5 percent of the contract value void in standard terms (BGH, VII ZR 210/01) |
| Credits as an exhaustive remedy | relationship to further damages | reservation on acceptance of performance required (section 341(3) German Civil Code) |
The report that is worth something in a dispute
At the end of the reference period there is a number, and the question is where it comes from. The IT-Recht Kanzlei states the client claim plainly: the client has to be given the opportunity to verify that the availability agreement has been met. A PDF with a single percentage does not do that, because nothing in it can be recalculated.
- Reference period with start and end time including time zone.
- The outage definition used, in full wording rather than as a reference to an annex.
- Every event separately: start, end, duration, affected measurement points, status code or error pattern.
- The maintenance windows deducted, listed individually with the date they were announced.
- The raw data basis: check interval, number of measurements, number of failed attempts.
- The calculation itself, so the percentage follows visibly from the lines above it.
- A deadline within which the recipient can object to the report.
Such a report is at once the basis for billing the credits and the defence against unfounded claims. It helps both sides because it moves the discussion from the percentage to the individual events, which can be discussed on the facts. A report per billing period and a public status page for clients serve two different needs: the archive and the present moment.
A service level agreement is rarely read closely when it is signed, and almost always read closely the first time two parties put two different numbers for the same month on the table.
Being able to attribute outages to their causes changes the negotiation. A drop that coincides with a release is a different matter from a network problem in the data centre: deploy errors as a cause of outages describes how to verify that. And anyone taking over or handing over a website should pass on the measurement record; a test report at acceptance shows the same logic for the moment of sign-off.
Measuring from the day the offer goes out means having a reference curve by the time the contract is signed, and knowing whether the promise being signed matches what the setup delivers today. An SLA that beats real availability by one more nine is not a sales argument but a provision that falls due in the first bad month.
Ten points to settle before signing
The following list can be worked through in a single meeting, usually in half an hour. Every point left open becomes a question of interpretation later, and in case of doubt interpretation does not favour the side that wrote the clause.
- From which locations is the check run, over which protocol, at which interval?
- Who operates the measuring point, and can the other side inspect the raw data?
- Which status codes count as success, and which content check runs alongside?
- From which response time onwards does an answer count as an outage?
- How many failed attempts from how many locations start an outage, and what ends it?
- Which reference period applies: month, quarter or year?
- When are maintenance windows, how long may they last at most, how early are they announced?
- When do response and restoration time start, and during which service hours do they run?
- Are the credits a contractual penalty or liquidated damages, and what is the cap measured against?
- Which report is delivered when, and in which form can it be objected to?
With these ten points answered, the rest is a negotiation about a number. Without them, both sides negotiate about a number that has not been defined yet. Agencies that give promises to several clients at once and accept promises from their own hosts are best served by keeping the points in one place and hanging the measurement off them: the area for agencies bundles the client accounts, and the SLA report per period is produced for every client by the same procedure.
This article draws on: the article of the German law firm IT-Recht Kanzlei on the service level agreement of 18 February 2010, the legal update of the law firm GÖRG of October 2024 on the 5 percent contractual penalty with the decisions BGH VII ZR 210/01 of 23 January 2003 and BGH VII ZR 42/22 of 15 February 2024, sections 305c, 307, 309, 310, 339 and 341 of the German Civil Code in the version promulgated on 2 January 2002, and RFC 9110 (HTTP Semantics, June 2022) for status codes 200, 503 and the 5xx class. The worked examples of 7.44 and 87.36 hours come from the IT-Recht Kanzlei article. Quotations from German sources are rendered in English here; the verbatim German wording is in the linked originals. This text is not legal advice for an individual case; contract clauses should be reviewed by a lawyer before use.