Skip to content 
I read every hosting contract SLA line by line because I need availability, Backup-guarantee and liability. This is how I recognize whether uptime promises, recovery times and Compensation really fit my website.
Key points
Before I sign, I record the most important checkpoints and categorize them according to my risk so that I don't overlook any blind spots and interpret every promise correctly. I weigh up the importance of uptime, support, data backup, security and liability in the context of my application and budget, rather than relying solely on marketing promises. I note that small deviations in percentage values have a big impact on downtimes and that support times at the weekend can have a completely different effect than on weekdays. I also take a close look at whether backups only exist or are really restored quickly and predictably. And I check whether liability limits even come close to my potential damage. intercept can.
- Uptime Specifically: 99.9% vs. 99.99% and what counts as downtime
- Support-Response times: Time logic and escalation
- Backups with storage, restore time and costs
- Security guaranteed: DDoS, 2FA, encryption
- Liability and credits: limits and exclusions
Read availability guarantee correctly
I first check the Uptime-I convert this into downtime per year so that I can see the real risk and not just percentages. 99.9% means up to 8.76 hours of downtime per year, 99.99% only around 52 minutes, which is often crucial for stores. I check whether the contract excludes planned maintenance from the downtime and at what times this maintenance takes place. If the contract states a 99.9% quota, but there are 2 hours of maintenance every Sunday, this massively shifts my planning scope. For more in-depth optimization, I use additional tips such as the Optimize uptime guarantee, so that I can derive concrete options for action from percentages.
Measurement methodology and scope of uptime
I clarify where the provider measures: at the network edge, at hypervisor level or as an end-to-end check up to the web response. Ping availability is of little use to me if the database or app layer is down. I record whether only the infrastructure counts or whether platform services (e.g. Managed DB, Object Storage) are also included in the availability. Equally important: the time zone of the measurement, the synchronization of the clocks and whether only complete minutes count or also seconds. I check whether third-party providers (DNS, CDN, email) count as exclusions and consciously plan my own SLAs for them.
I am looking at the definition of “incident”: At what point does downtime begin, and does it only end with full recovery or already with degradation. I demand clear rules on partial failures (e.g. only an availability zone error) and how these are included in the quota. Without a clear measurement logic, we are often talking at cross purposes when it comes to outages.
Really evaluate response times and support
I do not rely on a general Promise, but look for clear response time windows for different priorities. If support responds to P1 faults in 30 or 60 minutes, does the clock count from the time the ticket is opened or only during office hours, and does the escalation continue at night. I check whether requests on Friday evening wait until Monday, as this can cost entire weekends in the event of outages. I also pay attention to how the provider manages the solution (time to resolve) in relation to the initial response. An hour's response without a concrete solution plan is of little use to me if my store is still down. offline remains.
Monitoring, logs and incident transparency
I request access to a status page with historical availability and incident archives so that I can identify causes and recurrences. I check whether I can export metrics (CPU, RAM, I/O, latency) and logs to feed my own monitoring, alarms and SIEM. Log retention, access control and the ability to get audit logs for admin activities should be specified. I ask for postmortems with root cause analysis, corrective actions and deadlines so that learning effects become mandatory.
Making backups, storage and restores plannable
I look at backup frequency, retention time, recovery time and possible fees in the package, so that I don't have to improvise in the event of data loss and have real Security have. Daily backups are often sufficient for static pages, while editorial or store systems are better backed up hourly. Keeping backups for 30 to 90 days protects against late discoveries, for example in the event of errors being introduced unnoticed. The promised restore time is important, because a backup is of no use to me if the restore takes days in practice. For methodical planning, I rely on tried and tested Backup strategies so that frequency, test-restore and costs match.
| Aspect | Solid formulation | Risky formulation | Note |
|---|---|---|---|
| Backup frequency | Daily or hourly | „Regular“ without number | Create numbers Clarity |
| Storage | At least 30-90 days | Only 7 days | Longer history made possible Rollback |
| Restore time | „Within 2-6 hours“ | „As quickly as possible“ | No plan without a time window |
| Costs | Restore included | 50 € per hour | Avoid cost traps |
| Redundancy | Multiple locations | One location | Protection from Failures |
I test a restore to a staging environment at least quarterly, so that I know the steps in case of an emergency and can Duration realistically. This allows me to plan the restart and prevent surprises with rights, paths or databases. I also document who has access to backups to prevent operating errors. This is particularly important for productive stores with many orders per day. A documented restore process reduces my Risks noticeable.
Specify RPO, RTO and backup quality
I write my target recovery in two values: RPO (maximum data loss) and RTO (maximum restart time). For a store with ongoing orders, for example, I aim for RPO ≤ 15 minutes and RTO ≤ 2 hours. Then I check whether the backup frequency, the snapshot consistency (application-consistent vs. crash-consistent) and the restore capacities match. I ask for immutable backups or WORM storage so that ransomware does not destroy any history. I assume encryption at rest, as well as a clear regulation on key sovereignty if the provider uses KMS.
Securing disaster recovery and hardware replacement
I check whether the provider automatically detects hardware faults and replaces defective components in 30 to 120 minutes, because every minute of P1 malfunctions counts. Is the restoration from the last backup included in the contract, and is it included or subject to a charge. I check whether the provider automatically directs traffic to replacement systems during the swap. It is important that the SLA clearly states the responsibilities so that I have no gaps in responsibility in the event of an emergency. A clear DR regulation gives me real Resilience against failures.
Shared responsibility and responsibilities
I ask for a responsibility matrix: Which layers (physics, network, hypervisor, OS, middleware, app, data) are the responsibility of the provider and which are my responsibility. Patches for the operating system are the responsibility of the hoster in managed tariffs, but often my duty in self-managed variants. Without a clear dividing line, security and availability gaps remain invisible until the worst comes to the worst.
Understanding security as an integral part of the contract
I expect the SLA to include a clear commitment to firewalls, DDoS protection, regular malware scans, TLS encryption and 2FA. If these points are only in the marketing text, I demand a contractual specification with minimum standards. I check whether security functions are included in the basic package or whether additional costs will upset the calculation. It is also important how quickly security vulnerabilities are patched at OS or platform level. Without fixed response and update times, I lose valuable time in the event of incidents. Time.
Compliance, data protection and data location
I request an order processing contract with documented TOMs so that roles, access, deletion and retention periods are clear. I clarify in which countries data is stored and processed and whether subcontractors are listed. I check how data is exported on request and completely deleted at the end of the contract, ideally with confirmation of deletion. For sensitive environments, I demand regular security checks (e.g. pentests) and defined deadlines for rectifying critical findings.
Maintenance window regulated transparently
I have them explain to me exactly how often maintenance takes place, when it starts and how long it typically takes, so that I know my Peak times protect. Ideally, maintenance windows are outside of my main use and are announced well in advance, around 48 hours in advance. I also check whether the maintenance counts towards the availability quota or is explicitly excluded. Without this clarity, a supposedly high uptime figure can be deceptive. Transparency at this point saves me a lot later on. Discussions.
Realistically plan performance, retention and limits
I ask for hard metrics: guaranteed vCPU performance, RAM allocation, IOPS and throughput limits for storage, rate limits for APIs and network. I ask about measures against “noisy neighbors” in shared environments and whether bursting is allowed. For databases, I want to know how many simultaneous connections and transactions are supported before throttling takes effect. Without these figures, I run the risk of hidden bottlenecks exactly when I have peak loads.
Network quality and connectivity
I check whether there are binding statements on latency, packet loss and jitter between data centers or in defined regions. I ask about redundant upstreams, BGP failover, DDoS scrubbing windows and whether anycast or geo-routing is used. For my use cases with real-time components (e.g. live events), these network SLAs are often more relevant than a general uptime figure.
Check liability, credits and limits on a secular basis
I read the liability chapter line by line and calculate what indemnities mean in real terms so that I can calculate my Costs can be categorized. For example: 25% credit per full hour of downtime sounds good, but rarely covers potential loss of revenue. I check the maximum liability, often limited to one or two monthly fees, and decide whether I need additional insurance cover. Exclusions such as force majeure or customer errors are common, but should not lead to a blanket loss of cover. For context on obligations and scope, I also read the Legal obligations, to properly calibrate my expectations.
Apply for service credits correctly
I clarify how I request credits: Deadlines (often 30 days), proof (ticket IDs, monitoring receipts), contact persons and processing times. I check whether credits are issued automatically or have to be actively requested, and whether several incidents are accumulated. It is important to know whether credit notes are credited to the next invoice or expire. In this way, I prevent contractually agreed compensation from being lost in the process.
Scalability and resources without interruption
I pay attention to how quickly I can expand CPU, RAM, storage and traffic quotas so that I can achieve growth without Downtime cushion the impact. A defined provisioning period, such as „within 15 minutes“, and transparent prices before the upgrade are important. I check whether vertical upgrades trigger a reboot and whether horizontal scaling is available. For predictable peaks, I keep additional capacity available or book short-term quotas. In this way, I also stay on top of campaigns, releases or seasonal business capable of acting.
Control change management and deployments
I define change windows for updates to the stack with the provider so that releases, schema migrations and configuration changes are carried out with a rollback plan. I ask about blue/green or canary options and whether zero-downtime deployments are supported. For business-critical phases, I plan freeze periods so that no surprise changes fall into the peak season.
Clearly regulate migration, cutover and exit
I have the migration help, test environment and cutover plan confirmed. I reduce DNS TTL before the move, test a fallback to the old environment and ensure a data delta resync until shortly before going live. On exit, I require defined export formats (files, databases, objects) and a clear schedule for the final deletion, including confirmation. This allows me to remain agile without losing data or time.
Keeping an eye on prices, overage and adjustment clauses
I break down the cost structure: basic fee, storage/traffic overage, IP addresses, snapshots, restores, support levels, DDoS options. I check index or price adjustment clauses and whether they give me a special right of termination. I pay attention to the minimum term, notice period and renewal logic so that I don't inadvertently slip into long commitments. A clear cost matrix prevents my business case from being eroded by additional costs.
Reading a contract: avoid typical pitfalls
I have vague formulations translated into clear figures so that measurable results can be achieved „as quickly as possible“. Values becomes. I uncover hidden fees, such as chargeable restores or limited support quotas, which increase my monthly price. I check change rights: if the provider is allowed to unilaterally adjust service features, I need a special right of termination. I pay attention to clear notice periods and comprehensible exit processes, including data export. In this way, I ensure that I can change without losing data.
Checklist without bullet points, but crystal clear
I ask myself: Does the uptime commitment fulfill my sales and reputation risks, and does the maintenance count correctly in the Quote. Has the response time for critical priorities been clearly defined with times, escalation levels and weekends? Do backup frequency, retention, restore time and fees match my change rate and recovery target? Are security, patching and 2FA contractually defined and not just a marketing phrase. Are indemnities and liability caps realistic, or do I need additional Protection.
Concrete steps before signing
I request a complete service specification and compare it with my use case so that no Gap remains. I ask for a test phase with monitoring of my core metrics so that I can see real performance. I document clear escalation contacts for day, night and weekend. I plan a restore test in staging before my site goes live. And I ensure an exit plan with clean data export and a final Deletion sensitive content.
Briefly summarized
I actively read every contract, convert percentages into real minutes of absence and check what is considered Downtime is what counts. I demand measurable support and security promises instead of non-binding empty phrases. I plan backups with clear storage, tested recovery and fair cost logic. I assess liability limits against my potential damage and decide whether I need additional protection. This is how I choose a host that supports my goals and meets my Risks controllable.
