A published SLA is not a guarantee
An SLA is a contractual text, not a sales argument: it states what the host measures, what it excludes, and what it pays when it falls short. For an agency, the sensitive point is the gap between two contracts. Towards the client, it often signs a broad clause: site available, incidents handled quickly, data returnable. Towards the host, it relies on narrower clauses, sometimes with no commitment to a result at all. If the host caps its compensation at a service credit while the agency promises to make good the client's loss, the difference stays with the agency.
This article is a checklist of questions, not legal advice. The reach of a clause depends on its exact wording, the applicable law and your situation: have your contracts reviewed by a lawyer. It covers the general agency case; the obligations specific to financial entities are the subject of the article on DORA and ICT contracts.
Availability: what is measured, by whom, over what period
Start with the definition, because everything else depends on it. What does "available" mean: the server answers a network test, or the client's site actually loads? A host can measure the availability of its platform without ever looking at your application. Then ask who measures, with what tool, from which vantage point, and whether the records are open to the agency or only on request.
The calculation period matters as much as the rate. A rate assessed over a month or over a year does not translate into the same tolerated outage, and a failure split into micro-incidents may never cross the threshold. Also check whether the SLA covers the whole service or one component: network, storage, hypervisor, control panel. Finally, spot what is excluded from the measurement, because that is where the promise shrinks.
Exclusions to look for in the text
- Scheduled maintenance — are announced windows counted? With what notice, and with what limit on duration or frequency?
- Force majeure — is the list closed, or wide enough to cover an outage at your supplier's supplier?
- Third-party failures — upstream network, data center, DNS or CDN: are they excluded, even though the client only sees an offline site?
- Cause on the client side — does a configuration, a plugin or an abnormal load suffice to set the SLA aside, and who establishes the proof?
- Attacks and abuse — is a denial-of-service attack excluded, and from what protection threshold?
- Suspension for non-payment or abuse — does a suspended account drop out of the calculation unconditionally?
- Trigger threshold — is a continuous interruption of a minimum length required, or do cumulative outages count?
Compensation: cap, credit and claims procedure
An SLA is judged by what it costs the host to miss it. Look at the form of compensation: credit on the next invoice, refund, or indemnity. A service credit does not repair the lost revenue of an e-commerce client, and it can often only be used with the host itself. Then look at the cap: a percentage of the fee, a maximum amount, exclusion of certain kinds of loss.
The procedure matters as much as the amount. Is the credit automatic or conditional on a written claim? Within what time must it be filed, and through which channel? Many credits are never collected because the claim window has passed. Finally, note whether the SLA is the only possible remedy or whether other recourse remains open: that is a drafting question your lawyer must settle, not you.
Support: a response time is not a resolution time
Read the support commitments with the same grid. Distinguish acknowledgement, first useful response and resolution: a host can commit to the first and stay silent on the last. Check how incident severity is defined, and who decides it. If the host alone decides, a client site that is down can be ranked low severity.
Ask about the available channels (ticket, email, phone), the hours, the languages, and what happens outside business hours. A weekend or public holiday without on-call cover is enough to make an agency promise untenable. Finally, ask how the agency escalates: is there a named contact for reseller accounts, and a separate channel for major incidents? That is the chain you will describe to your client, so know it before you do.
Backups: included, retained, restorable?
The word "backup" in a contract says almost nothing. Ask precise questions. Is it included in the plan or optional? What is its frequency and retention period? Where is it stored: on the same machine or elsewhere? A copy on the server it protects goes down with it.
The point agencies discover too late is restoration. Who triggers it, within what time, at what cost, and over what scope: the whole site, the database, a single file? Does the contract guarantee restorability, or only that a copy exists? A backup that has never been tested remains a hypothesis. Plan a regular restoration test on a client site, as our dedicated procedure describes, and keep a copy independent of the host's for the sites that matter.
Back-to-back: what you promise versus what the host guarantees
Scroll the table
| Commitment to the client | What the host must guarantee | Gap to close |
|---|---|---|
| Site available to a threshold | An SLA measured on the same scope, over the same period | Different definition: adapt the promise or the scope |
| Compensation for an outage | Compensation at least equivalent, with no lower cap | Lower cap: the difference stays with the agency |
| Quick response to an incident | A first-response time and a defined severity | Resolution time not guaranteed: do not promise it |
| Intervention outside business hours | On-call cover or extended support | No on-call: provide your own or exclude it |
| Backup and restoration | Frequency, retention, restoration time and cost | Paid or slow restoration: plan your own copy |
| Return of data at end of contract | Export in a usable format, within a set time | No exit clause: negotiate before signing |
| Information during an incident | A commitment to notify and communicate | No notification: you inform the client without proof |
Exit and reversibility: the day the client leaves
The exit clause is the one read last and needed first on the day of a dispute. A client may leave, the agency may change host, the host may cease trading. In each case you must be able to recover the site, the database, the mailboxes and the DNS settings in a usable format.
So ask: within what time is data returned after termination? In what format? At what price? How long does the host keep it before deletion, and is deletion confirmed? Check the termination notice, which determines whether you can change host without interruption, and any fees. Finally, look at who owns the domain names and certificates: a domain registered in the host's name complicates any exit.
Subcontracting, data location and maintenance
- Subcontracting — can the host hand operations to a third party, must it tell you, and does it remain liable for its subcontractors?
- Data location — in which countries are data and backups stored, and is a change of location notified?
- Maintenance notice — what minimum delay, through which channel, and what happens for an urgent intervention?
- Security — which measures are described, and does the host commit to warn you of an incident affecting your data?
- Changes to the contract — can the host alter the terms unilaterally, and with what notice on your side?
- Liability — what does the text say about indirect damage, data loss and the overall liability limit?
- Governing law — which law and which courts govern the contract, and are they compatible with those you sign with the client?
Aligning the client contract with the host's
Gather the texts
Collect the host's contract, SLA, terms of service, backup policy and support policy. The commitments are often spread across several documents.
Fill in the back-to-back table
For each commitment the client asks for, note the matching clause at the host. A row with no clause is a gap, not a detail.
Rank the gaps
For each one, choose: close it (obtain a commitment from the host), reduce it (promise less), or accept it (the risk stays with the agency, knowingly).
Reword the promise to the client
Write commitments of means and procedure rather than a numeric result, until the host gives you the equivalent upstream.
Submit to the lawyer
Send the table and both sets of clauses. A lawyer validates the whole; this checklist does not replace that step.
Review at each renewal
A host changes its terms, the agency changes its scope. Schedule the review at each renewal date, and at each change of host.
A rule for the client wording
Never carry a figure from the host's SLA into your contract without having read its definition, its exclusions and its cap. A rate copied without its context becomes your commitment, without the protection that surrounded it at the host.
What this checklist does not cover
The checklist says nothing about the law applicable to your situation, the validity of a limitation clause, or your clients' sector obligations. It replaces neither legal advice nor reading the texts in full. Its use is to reach the lawyer with the right questions, rather than with an SLA whose exclusions nobody has read.
For the ServOrbit platform, the availability mentioned on the site is a target, not a contractual commitment: it is read with this same grid, checked against the terms of service, and not carried over as is into your contracts. Our role is to run the infrastructure; yours remains the client relationship, and the contractual base that carries it.
