{"id":3956,"date":"2026-01-01T23:58:39","date_gmt":"2026-01-01T20:58:39","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/how-to-read-hosting-slas-and-terms\/"},"modified":"2026-01-01T23:58:39","modified_gmt":"2026-01-01T20:58:39","slug":"how-to-read-hosting-slas-and-terms","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/how-to-read-hosting-slas-and-terms\/","title":{"rendered":"How to Read Hosting SLAs and Terms"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Most people sign up for hosting by comparing disk space, bandwidth and price, then scroll past the SLA and terms as fast as possible. Months later, a short outage or a resource limit kicks in, and that same fine print suddenly becomes very important. If you run an e\u2011commerce store, agency portfolio, SaaS app or even a busy blog, the way your hosting <strong>SLA (Service Level Agreement)<\/strong> and terms are written can directly affect your revenue, reputation and support workload.<\/p>\n<p>In this article, we will walk through how to read hosting SLAs and terms like a technical decision-maker, not just a buyer checking out a cart. We will decode <strong>uptime percentages<\/strong> (99.5%, 99.9%, 99.99%), explain how <strong>refund policies and service credits<\/strong> actually work, and highlight the <strong>hidden limits<\/strong> that often sit behind words like \u201cunlimited\u201d. As the dchost.com team, we see both sides every day: real customer expectations and what the contract actually promises. The goal here is simple: after reading, you should be able to look at any hosting SLA and quickly decide whether it matches the risk level and uptime your project really needs.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Hosting_SLAs_Matter_More_Than_Price_Tags\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Hosting SLAs Matter More Than Price Tags<\/a><\/li><li><a href=\"#Decoding_Uptime_Percentages_What_995_999_and_9999_Really_Mean\"><span class=\"toc_number toc_depth_1\">2<\/span> Decoding Uptime Percentages: What 99.5%, 99.9% and 99.99% Really Mean<\/a><ul><li><a href=\"#How_Uptime_Is_Calculated\"><span class=\"toc_number toc_depth_2\">2.1<\/span> How Uptime Is Calculated<\/a><\/li><li><a href=\"#What_Exactly_Counts_as_Downtime\"><span class=\"toc_number toc_depth_2\">2.2<\/span> What Exactly Counts as Downtime?<\/a><\/li><li><a href=\"#Common_Uptime_Gotchas_Hidden_in_SLAs\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Common Uptime Gotchas Hidden in SLAs<\/a><\/li><\/ul><\/li><li><a href=\"#Refunds_vs_Service_Credits_How_SLA_Compensation_Really_Works\"><span class=\"toc_number toc_depth_1\">3<\/span> Refunds vs Service Credits: How SLA Compensation Really Works<\/a><ul><li><a href=\"#Typical_SLA_Compensation_Model\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Typical SLA Compensation Model<\/a><\/li><li><a href=\"#Questions_to_Ask_About_SLA_Credits\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Questions to Ask About SLA Credits<\/a><\/li><li><a href=\"#Example_Calculating_a_Credit_from_Downtime\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Example: Calculating a Credit from Downtime<\/a><\/li><\/ul><\/li><li><a href=\"#Hidden_Limits_in_Hosting_Terms_You_Should_Always_Check\"><span class=\"toc_number toc_depth_1\">4<\/span> Hidden Limits in Hosting Terms You Should Always Check<\/a><ul><li><a href=\"#1_Unlimited_Disk_Space_and_Bandwidth\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. \u201cUnlimited\u201d Disk Space and Bandwidth<\/a><\/li><li><a href=\"#2_CPU_RAM_and_IO_Throttling_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. CPU, RAM and I\/O Throttling on Shared Hosting<\/a><\/li><li><a href=\"#3_Email_Sending_Limits_and_Spam_Policies\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Email Sending Limits and Spam Policies<\/a><\/li><li><a href=\"#4_Backup_and_Retention_Policies\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. Backup and Retention Policies<\/a><\/li><li><a href=\"#5_Support_Scope_Response_Times_and_Managed_vs_Unmanaged\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. Support Scope, Response Times and Managed vs Unmanaged<\/a><\/li><li><a href=\"#6_IP_Addresses_IPv4_Scarcity_and_Extra_Charges\"><span class=\"toc_number toc_depth_2\">4.6<\/span> 6. IP Addresses, IPv4 Scarcity and Extra Charges<\/a><\/li><\/ul><\/li><li><a href=\"#Maintenance_Windows_Force_Majeure_and_Other_Fine_Print\"><span class=\"toc_number toc_depth_1\">5<\/span> Maintenance Windows, Force Majeure and Other Fine Print<\/a><ul><li><a href=\"#Scheduled_Maintenance\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Scheduled Maintenance<\/a><\/li><li><a href=\"#Force_Majeure_and_External_Dependencies\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Force Majeure and External Dependencies<\/a><\/li><\/ul><\/li><li><a href=\"#How_We_Approach_SLAs_and_Terms_at_dchostcom\"><span class=\"toc_number toc_depth_1\">6<\/span> How We Approach SLAs and Terms at dchost.com<\/a><\/li><li><a href=\"#Practical_Checklist_Reviewing_a_Hosting_SLA_Before_You_Commit\"><span class=\"toc_number toc_depth_1\">7<\/span> Practical Checklist: Reviewing a Hosting SLA Before You Commit<\/a><\/li><li><a href=\"#Wrapping_Up_Turn_SLAs_from_Legalese_into_a_Tool_You_Actually_Use\"><span class=\"toc_number toc_depth_1\">8<\/span> Wrapping Up: Turn SLAs from Legalese into a Tool You Actually Use<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Hosting_SLAs_Matter_More_Than_Price_Tags\">Why Hosting SLAs Matter More Than Price Tags<\/span><\/h2>\n<p>A hosting SLA is not just legal decoration. It is a technical promise translated into contractual language. It defines:<\/p>\n<ul>\n<li><strong>Availability<\/strong>: How often your service is expected to be reachable.<\/li>\n<li><strong>Scope<\/strong>: Exactly <em>what<\/em> is being guaranteed (network, power, control panel, whole stack?).<\/li>\n<li><strong>Compensation<\/strong>: What happens if the provider does not meet the target.<\/li>\n<li><strong>Responsibilities<\/strong>: Which parts are your job (e.g. application bugs, configuration) and which belong to the provider.<\/li>\n<\/ul>\n<p>If you are running a casual personal blog, a light SLA might be acceptable. For a store that processes payments 24\/7, or an agency hosting dozens of client sites, the SLA becomes part of your own promise to your customers. A weak SLA can create an ugly chain reaction: a few minutes of downtime, confused support responses, no meaningful credits, and you stuck explaining \u201cour provider says this was scheduled maintenance, so it does not count.\u201d<\/p>\n<p>We have a separate article dedicated to <a href=\"https:\/\/www.dchost.com\/blog\/en\/99-9-uptime-ne-anlama-gelir-hosting-sla-sozlesmelerini-okuma-rehberi\/\">what 99.9% uptime really means and how to read uptime SLAs without guessing<\/a>. Here we will go broader and include refund policies and the hidden limits that rarely appear on the pricing page.<\/p>\n<h2><span id=\"Decoding_Uptime_Percentages_What_995_999_and_9999_Really_Mean\">Decoding Uptime Percentages: What 99.5%, 99.9% and 99.99% Really Mean<\/span><\/h2>\n<p>Uptime is usually the first big number you see in a hosting SLA: 99.5%, 99.9%, 99.95%, 99.99%\u2026 They all look high, but the real question is: <strong>how much downtime is actually allowed<\/strong>?<\/p>\n<h3><span id=\"How_Uptime_Is_Calculated\">How Uptime Is Calculated<\/span><\/h3>\n<p>In most SLAs, uptime is calculated as:<\/p>\n<p><code>Uptime % = (Total time - Downtime) \/ Total time \u00d7 100<\/code><\/p>\n<p>\u201cTotal time\u201d is usually one month. So if a month has 30 days:<\/p>\n<ul>\n<li>Total minutes in month = 30 \u00d7 24 \u00d7 60 = 43,200 minutes.<\/li>\n<\/ul>\n<p>Here is what common uptime percentages allow as downtime per month and per year:<\/p>\n<table border=\"1\" cellspacing=\"0\" cellpadding=\"6\">\n<tr>\n<th>Uptime SLA<\/th>\n<th>Max downtime \/ month<\/th>\n<th>Max downtime \/ year (approx.)<\/th>\n<\/tr>\n<tr>\n<td>99.0%<\/td>\n<td>~432 minutes (~7.2 hours)<\/td>\n<td>~3.65 days<\/td>\n<\/tr>\n<tr>\n<td>99.5%<\/td>\n<td>~216 minutes (~3.6 hours)<\/td>\n<td>~1.83 days<\/td>\n<\/tr>\n<tr>\n<td>99.9%<\/td>\n<td>~43 minutes<\/td>\n<td>~8.76 hours<\/td>\n<\/tr>\n<tr>\n<td>99.95%<\/td>\n<td>~22 minutes<\/td>\n<td>~4.38 hours<\/td>\n<\/tr>\n<tr>\n<td>99.99%<\/td>\n<td>~4.3 minutes<\/td>\n<td>~52.6 minutes<\/td>\n<\/tr>\n<\/table>\n<p>Notice how the difference between 99.9% and 99.99% is not \u201c0.09%\u201d; it is the difference between tolerating <strong>about 43 minutes vs about 4 minutes<\/strong> of outage in a month.<\/p>\n<h3><span id=\"What_Exactly_Counts_as_Downtime\">What Exactly Counts as Downtime?<\/span><\/h3>\n<p>This is the first place the SLA details really matter. Typical questions to check:<\/p>\n<ul>\n<li><strong>What layer is guaranteed?<\/strong> Network only? Power only? Or the full hosting service including web server and database?<\/li>\n<li><strong>How is downtime measured?<\/strong> From the provider&#039;s monitoring, from your monitoring, or both?<\/li>\n<li><strong>Is degraded performance counted?<\/strong> For example, if the site responds in 30 seconds instead of 1 second, does this count as \u201cup\u201d or \u201cdown\u201d?<\/li>\n<li><strong>Is DNS included?<\/strong> If DNS is unavailable but servers are fine, does that count?<\/li>\n<\/ul>\n<p>Some SLAs only measure core network connectivity inside the data center. Others commit to the full hosting stack, which is more meaningful for most website owners. At dchost.com we pay close attention to this distinction internally: network uptime is one metric, but what matters to you is whether your site actually answers visitors in a reasonable time.<\/p>\n<p>If you want to go deeper into availability concepts in general, we also recommend our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/uptime-nedir-web-siteleri-icin-surekli-erisilebilirlik-saglamanin-yollari\/\">what uptime is and how to ensure continuous availability for websites<\/a>.<\/p>\n<h3><span id=\"Common_Uptime_Gotchas_Hidden_in_SLAs\">Common Uptime Gotchas Hidden in SLAs<\/span><\/h3>\n<p>Even when a provider advertises 99.9% or 99.99%, there are often exclusions that significantly reduce what you actually get. Always look for these sections:<\/p>\n<ul>\n<li><strong>Scheduled maintenance<\/strong>: Many SLAs exclude planned maintenance windows completely, even if they happen during your peak hours.<\/li>\n<li><strong>Force majeure<\/strong>: Natural disasters, regional power grid issues, large-scale internet problems, etc., are typically excluded.<\/li>\n<li><strong>Customer-caused incidents<\/strong>: Misconfiguration, insecure scripts, abusive traffic generated by your site, or exceeding resource limits usually do not count as SLA downtime.<\/li>\n<li><strong>DDoS attacks<\/strong>: If the provider offers basic protection but a larger DDoS still affects your service, check whether this is covered or excluded.<\/li>\n<\/ul>\n<p>We have a whole guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/kucuk-ve-orta-olcekli-siteler-icin-ddos-koruma-stratejileri\/\">DDoS protection strategies for small and medium websites<\/a>; it is worth understanding how your own mitigation setup aligns with the SLA language around attacks.<\/p>\n<h2><span id=\"Refunds_vs_Service_Credits_How_SLA_Compensation_Really_Works\">Refunds vs Service Credits: How SLA Compensation Really Works<\/span><\/h2>\n<p>Many people assume that if an SLA is breached, they will \u201cget their money back.\u201d In reality, most hosting SLAs compensate you with <strong>service credits<\/strong>, not cash refunds, and often only if you follow a specific process.<\/p>\n<h3><span id=\"Typical_SLA_Compensation_Model\">Typical SLA Compensation Model<\/span><\/h3>\n<p>While every provider is different, a common pattern looks like this:<\/p>\n<ul>\n<li>Uptime is checked monthly (for example, 99.9% target).<\/li>\n<li>If actual uptime falls below that target, you become <em>eligible<\/em> for a credit.<\/li>\n<li>You must open a ticket within a certain time frame (e.g. 7\u201330 days) to request the credit.<\/li>\n<li>The credit is applied to a future invoice, not refunded to your payment card.<\/li>\n<li>Credits are capped (for example, maximum 50\u2013100% of that month\u2019s fee).<\/li>\n<\/ul>\n<p>The exact percentages vary. You may see language like: \u201cIf monthly uptime is between 99.0% and 99.9%, customer is entitled to a 10% credit; between 95.0% and 99.0%, a 25% credit; below 95.0%, a 100% credit.\u201d The key takeaway: <strong>you usually need to ask for it<\/strong>, and the amount is tied to the hosting fee only, not your lost revenue.<\/p>\n<h3><span id=\"Questions_to_Ask_About_SLA_Credits\">Questions to Ask About SLA Credits<\/span><\/h3>\n<p>When reviewing an SLA, it is useful to answer these questions explicitly:<\/p>\n<ul>\n<li><strong>Is compensation automatic?<\/strong> Or must you file a claim ticket?<\/li>\n<li><strong>What proof is required?<\/strong> Provider logs only, or do they accept your own monitoring data?<\/li>\n<li><strong>What is the timeframe?<\/strong> How many days after the incident do you have to claim?<\/li>\n<li><strong>What is the maximum credit?<\/strong> Can it exceed the monthly fee if the outage is severe?<\/li>\n<li><strong>Does compensation apply to add-ons?<\/strong> For example, extra IPs, backups, or dedicated hardware?<\/li>\n<\/ul>\n<p>At dchost.com we design SLAs to be understandable from the start: if there is an uptime guarantee, we also make clear what the process is for claiming credits and which services are covered. The aim is not to hide behind process, but to have a predictable, auditable way to handle rare incidents.<\/p>\n<h3><span id=\"Example_Calculating_a_Credit_from_Downtime\">Example: Calculating a Credit from Downtime<\/span><\/h3>\n<p>Imagine a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> plan costs 50 \u20ac per month and comes with a 99.9% uptime SLA. In one month, you experience 90 minutes of verified downtime that is counted under the SLA.<\/p>\n<ul>\n<li>Max allowed downtime at 99.9% \u2248 43 minutes.<\/li>\n<li>Actual downtime: 90 minutes.<\/li>\n<li>SLA shortfall: 90 \u2212 43 = 47 minutes.<\/li>\n<\/ul>\n<p>Now assume the SLA states:<\/p>\n<ul>\n<li>99.0\u201399.9%: 10% credit<\/li>\n<li>95.0\u201399.0%: 25% credit<\/li>\n<li>&lt; 95.0%: 100% credit<\/li>\n<\/ul>\n<p>90 minutes of downtime in a 30\u2011day month gives roughly 99.79% uptime, which falls into the 10% credit band. Your credit would be:<\/p>\n<p><code>50 \u20ac \u00d7 10% = 5 \u20ac<\/code><\/p>\n<p>Next month, 5 \u20ac is discounted from your bill. There is no extra compensation for lost sales or marketing spend. That is why for critical projects, you should pair SLA protection with your own <strong>uptime monitoring<\/strong> and a <strong>solid backup and disaster\u2011recovery plan<\/strong>.<\/p>\n<p>For monitoring, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/\">website uptime monitoring and alerting guide for small businesses<\/a> is a practical place to start.<\/p>\n<h2><span id=\"Hidden_Limits_in_Hosting_Terms_You_Should_Always_Check\">Hidden Limits in Hosting Terms You Should Always Check<\/span><\/h2>\n<p>Advertising space is limited; terms of service are not. Many important limits never appear on the pricing page but live deep inside the T&amp;Cs or Acceptable Use Policy. Here are the main ones you should always look for.<\/p>\n<h3><span id=\"1_Unlimited_Disk_Space_and_Bandwidth\">1. \u201cUnlimited\u201d Disk Space and Bandwidth<\/span><\/h3>\n<p>\u201cUnlimited\u201d often really means \u201c<strong>no fixed quota, but subject to fair use<\/strong>.\u201d Common hidden details include:<\/p>\n<ul>\n<li><strong>File count (inode) limits<\/strong>: Even if disk space is unlimited, the number of files and directories may be restricted.<\/li>\n<li><strong>Type of content<\/strong>: Some providers forbid using shared hosting as pure backup storage, file sharing, or archival.<\/li>\n<li><strong>Backup eligibility<\/strong>: Accounts above a certain size (for example, 50\u2013100 GB) may be excluded from automatic backups.<\/li>\n<li><strong>Bandwidth shaping<\/strong>: After a certain traffic level, your connection might be throttled or require an upgrade.<\/li>\n<\/ul>\n<p>We have written an entire piece on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-inode-limitine-takilmamak-icin-uygulamali-temizlik-rehberi\/\">how to avoid inode limits on shared hosting<\/a>. Reading that together with your provider&#039;s \u201cunlimited\u201d claims will give you a much clearer picture of what you can actually store.<\/p>\n<h3><span id=\"2_CPU_RAM_and_IO_Throttling_on_Shared_Hosting\">2. CPU, RAM and I\/O Throttling on Shared Hosting<\/span><\/h3>\n<p>Even on \u201cunlimited\u201d shared hosting, each account typically has:<\/p>\n<ul>\n<li>A maximum number of CPU cores or percentage of CPU time.<\/li>\n<li>Limits on RAM usage per process or per account.<\/li>\n<li>I\/O limits (how fast you can read\/write to disk).<\/li>\n<li>Entry process or concurrent connection limits.<\/li>\n<\/ul>\n<p>These limits protect other customers from \u201cnoisy neighbours\u201d, but they also mean that a sudden spike in your site traffic can hit a wall even if your disk and bandwidth are far from \u201cfull\u201d. When you see errors like \u201cResource limit reached\u201d or random 503s under load, you are often running into these caps.<\/p>\n<p>To understand these mechanisms better, have a look at our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-kaynak-limitleri-cpu-io-ep-ram-ve-resource-limit-reached-hatasi\/\">cPanel resource limits and fixing the \u201cResource Limit Reached\u201d error<\/a>. It explains how CPU, I\/O and concurrent process limits are enforced in real shared hosting environments.<\/p>\n<h3><span id=\"3_Email_Sending_Limits_and_Spam_Policies\">3. Email Sending Limits and Spam Policies<\/span><\/h3>\n<p>Email is another classic area where limits live in the fine print:<\/p>\n<ul>\n<li>Maximum emails per hour or per day per account.<\/li>\n<li>Restrictions on bulk or marketing email from shared hosting.<\/li>\n<li>Requirements to use authenticated SMTP, SPF, DKIM and DMARC.<\/li>\n<li>Automatic blocking or suspension if your messages trigger spam complaints or blocklists.<\/li>\n<\/ul>\n<p>If your business relies heavily on transactional or marketing email, you should know exactly how many messages per hour you can send and what the escalation path is if something gets flagged as spam. Combine this with solid DNS configuration and reputation management. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e-postalar-neden-spam-klasorune-dusuyor-paylasimli-hosting-ve-vps-icin-teslim-edilebilirlik-kontrol-listesi\/\">why emails go to spam and how to improve deliverability on shared hosting and VPS<\/a> is a good starting checklist.<\/p>\n<h3><span id=\"4_Backup_and_Retention_Policies\">4. Backup and Retention Policies<\/span><\/h3>\n<p>Almost every hosting landing page mentions \u201cfree backups,\u201d but the details vary hugely and are always defined in the terms:<\/p>\n<ul>\n<li><strong>Frequency<\/strong>: Daily, weekly, hourly? Full or incremental?<\/li>\n<li><strong>Retention<\/strong>: How many restore points are kept? 7 days, 30 days, more?<\/li>\n<li><strong>Scope<\/strong>: Files only, or databases and email as well?<\/li>\n<li><strong>Location<\/strong>: Same server, same data center, or geographically separate?<\/li>\n<li><strong>Guarantees<\/strong>: Are backups \u201cbest effort\u201d or covered by an SLA?<\/li>\n<\/ul>\n<p>Many providers explicitly say backups are not guaranteed and are for convenience only. That means your <strong>real recovery guarantee<\/strong> depends on your own backup strategy, not just what comes bundled with the hosting plan.<\/p>\n<p>We strongly recommend reading our explanation of the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3\u20112\u20111 backup strategy and how to automate backups on cPanel, Plesk and VPS<\/a>. It will help you design a backup plan that does not fall apart when you actually need a restore.<\/p>\n<h3><span id=\"5_Support_Scope_Response_Times_and_Managed_vs_Unmanaged\">5. Support Scope, Response Times and Managed vs Unmanaged<\/span><\/h3>\n<p>The SLA and ToS also define <strong>what the support team is responsible for<\/strong> and how fast they aim to respond:<\/p>\n<ul>\n<li>Is your plan <strong>managed<\/strong> (provider maintains OS, patches, services) or <strong>unmanaged<\/strong> (you manage everything above the hypervisor)?<\/li>\n<li>Are application-level issues (for example, WordPress plug\u2011ins, custom code) supported or best\u2011effort only?<\/li>\n<li>Are there target <strong>response times<\/strong> for critical tickets, or only general \u201cwe aim to respond quickly\u201d statements?<\/li>\n<li>Is 24\/7 support truly 24\/7 with engineers, or only ticket reception outside office hours?<\/li>\n<\/ul>\n<p>For teams moving from shared hosting to VPS, these questions are crucial. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/managed-vs-unmanaged-vps-hosting-hangi-is-yuku-icin-hangisi-dogru\/\">managed vs unmanaged VPS hosting, responsibilities and hidden costs<\/a> goes through real\u2011world examples of where the provider\u2019s job ends and yours begins.<\/p>\n<h3><span id=\"6_IP_Addresses_IPv4_Scarcity_and_Extra_Charges\">6. IP Addresses, IPv4 Scarcity and Extra Charges<\/span><\/h3>\n<p>Public IPv4 addresses have become significantly more expensive in recent years, and this often shows up in hosting terms before it shows on the main pricing page:<\/p>\n<ul>\n<li>Extra monthly fees per dedicated IPv4 address.<\/li>\n<li>Limits on how many IPs you can attach to one server or account.<\/li>\n<li>Justification policies (for example, requiring a technical reason for multiple IPs).<\/li>\n<li>Rules for IP reputation, blacklisting and abuse complaints.<\/li>\n<\/ul>\n<p>If your stack uses many IPs (SSL on older stacks, separate IPs for email, staging, etc.), factor these policies into your long\u2011term budget. For deeper context, we have written extensively about <a href=\"https:\/\/www.dchost.com\/blog\/en\/ipv4-adres-fiyatlari-rekor-kiriyor-neden-ne-zaman-nasil-cozulur\/\">why IPv4 address prices are hitting record highs and what you can do about it<\/a>. Understanding that bigger picture makes the IP section of the ToS much easier to read.<\/p>\n<h2><span id=\"Maintenance_Windows_Force_Majeure_and_Other_Fine_Print\">Maintenance Windows, Force Majeure and Other Fine Print<\/span><\/h2>\n<p>Two sections are often skipped but have a big impact on real\u2011world uptime: <strong>maintenance windows<\/strong> and <strong>force majeure<\/strong>.<\/p>\n<h3><span id=\"Scheduled_Maintenance\">Scheduled Maintenance<\/span><\/h3>\n<p>Most hosting providers reserve the right to perform maintenance on the underlying infrastructure. Key things to check:<\/p>\n<ul>\n<li><strong>Notification period<\/strong>: Do they promise to warn you in advance (for example, 3\u20137 days)?<\/li>\n<li><strong>Time windows<\/strong>: Is maintenance concentrated in off\u2011peak hours for your region, or only for the data center time zone?<\/li>\n<li><strong>Inclusion in uptime<\/strong>: Is scheduled maintenance excluded from uptime calculations?<\/li>\n<li><strong>Expected impact<\/strong>: Do they commit to keeping maintenance windows short and minimizing downtime?<\/li>\n<\/ul>\n<p>For example, an SLA may say that up to 2 hours per month of scheduled maintenance is not counted as downtime. If that maintenance always falls right in the middle of your own traffic peak, the effective availability for your business is lower than the advertised SLA number suggests.<\/p>\n<h3><span id=\"Force_Majeure_and_External_Dependencies\">Force Majeure and External Dependencies<\/span><\/h3>\n<p>Force majeure clauses list events that are beyond the provider\u2019s reasonable control. Typical examples:<\/p>\n<ul>\n<li>Natural disasters (earthquakes, floods, fires).<\/li>\n<li>Widespread power grid failures.<\/li>\n<li>Large\u2011scale routing issues on the global internet.<\/li>\n<li>Regional government\u2011mandated shutdowns.<\/li>\n<\/ul>\n<p>These clauses are standard in contracts, but you still want to understand how they might apply. For multi\u2011region or multi\u2011provider architectures, you can mitigate many of these risks on your side with redundancy and failover planning, even if they are not covered by SLA credits.<\/p>\n<p>That is where an explicit disaster\u2011recovery (DR) plan comes in. If you are designing or updating yours, our practical guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/felaket-kurtarma-plani-nasil-yazilir-rto-rpoyu-kafada-netlestirip-yedek-testleri-ve-runbooklari-gercekten-calisir-hale-getirmek\/\">how to write a no\u2011drama DR plan with clear RPO\/RTO and real restore drills<\/a> will help you connect the dots between SLAs and your own responsibilities.<\/p>\n<h2><span id=\"How_We_Approach_SLAs_and_Terms_at_dchostcom\">How We Approach SLAs and Terms at dchost.com<\/span><\/h2>\n<p>From the dchost.com side, we see SLAs as part of the product, not just legal text. For our shared hosting, VPS, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s and colocation services, we design SLA and terms with a few guiding principles:<\/p>\n<ul>\n<li><strong>Clarity over marketing<\/strong>: If we publish an uptime target, we also define what layer it applies to and how downtime is measured.<\/li>\n<li><strong>Realistic guarantees<\/strong>: We would rather commit to a strong SLA we can consistently meet than promise unrealistic \u201c100% uptime\u201d that quietly excludes half of real incidents.<\/li>\n<li><strong>Transparent responsibilities<\/strong>: Especially for VPS, dedicated and colocation, we make it clear which parts of the stack we manage and which you control.<\/li>\n<li><strong>Actionable processes<\/strong>: For credits, escalations or restore requests, we aim to have processes that are simple, documented and testable.<\/li>\n<\/ul>\n<p>On the operational side, our teams use monitoring, capacity planning, redundancy and backup strategies very similar to what we explain publicly on the blog. The same patterns behind our articles on uptime, monitoring, backups, IPv4 strategy and DR planning are reflected in how we run our own infrastructure for customers.<\/p>\n<p>When you evaluate any provider (including us), do not hesitate to ask support specific SLA questions: how they measure incidents, how often credits are actually granted, and what internal playbooks look like when there is a large outage. Good answers here are often a stronger reliability signal than the raw uptime number on the front page.<\/p>\n<h2><span id=\"Practical_Checklist_Reviewing_a_Hosting_SLA_Before_You_Commit\">Practical Checklist: Reviewing a Hosting SLA Before You Commit<\/span><\/h2>\n<p>To make this concrete, here is a quick checklist you can use the next time you are about to sign up for a hosting plan or move infrastructure.<\/p>\n<ol>\n<li>\n    <strong>Uptime target and scope<\/strong><\/p>\n<ul>\n<li>What percentage is promised (99.5%, 99.9%, 99.99%)?<\/li>\n<li>Does it cover network only, or the full hosting service?<\/li>\n<li>Is DNS part of the uptime calculation?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Downtime definition<\/strong><\/p>\n<ul>\n<li>What exactly counts as downtime (complete outage, errors above a threshold, extreme latency)?<\/li>\n<li>Are partial outages counted (some customers affected, some not)?<\/li>\n<li>Is scheduled maintenance excluded, and if so, under what conditions?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Measurement and evidence<\/strong><\/p>\n<ul>\n<li>Whose monitoring is authoritative\u2014the provider\u2019s, yours, or both?<\/li>\n<li>Can you submit your own logs or status pages as evidence?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Compensation model<\/strong><\/p>\n<ul>\n<li>Are there clear bands (for example, 99.0\u201399.9% \u2192 10% credit)?<\/li>\n<li>Is compensation automatic or do you need to open a ticket?<\/li>\n<li>What is the maximum monthly credit?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Resource limits<\/strong><\/p>\n<ul>\n<li>What are the CPU, RAM, I\/O, inode and bandwidth limits for your plan?<\/li>\n<li>Are there specific thresholds that trigger throttling or suspension?<\/li>\n<li>Are \u201cunlimited\u201d resources subject to fair use wording?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Email and IP policies<\/strong><\/p>\n<ul>\n<li>What are the hourly\/daily email send limits?<\/li>\n<li>What are the rules around bulk email and spam complaints?<\/li>\n<li>How many IPv4 addresses are included, and what are the extra costs?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Backup and restore<\/strong><\/p>\n<ul>\n<li>How often are backups taken and how long are they kept?<\/li>\n<li>What is the process and typical time to restore a backup?<\/li>\n<li>Are backups themselves part of any SLA?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Support scope and response<\/strong><\/p>\n<ul>\n<li>Is the service managed or unmanaged?<\/li>\n<li>What are the target response times for critical tickets?<\/li>\n<li>Are application issues covered or best\u2011effort only?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Maintenance and force majeure<\/strong><\/p>\n<ul>\n<li>How much scheduled maintenance per month is expected?<\/li>\n<li>How far in advance are you notified?<\/li>\n<li>What events are excluded as force majeure?<\/li>\n<\/ul>\n<\/li>\n<li>\n    <strong>Exit and migration<\/strong><\/p>\n<ul>\n<li>How easy is it to get a full backup of your data if you leave?<\/li>\n<li>Are there any fees or conditions related to migration or termination?<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h2><span id=\"Wrapping_Up_Turn_SLAs_from_Legalese_into_a_Tool_You_Actually_Use\">Wrapping Up: Turn SLAs from Legalese into a Tool You Actually Use<\/span><\/h2>\n<p>Hosting SLAs and terms do not have to be mysterious or intimidating. Once you know where to look\u2014uptime definitions, exclusions, compensation rules, hidden resource limits and backup policies\u2014they become a practical tool to align expectations between you and your provider. Instead of discovering limits during a crisis, you can decide up front which trade\u2011offs are acceptable and where you need stronger guarantees or additional redundancy.<\/p>\n<p>As the dchost.com team, our recommendation is to treat the SLA as an integral part of your infrastructure design. Pair it with your own monitoring, backup and disaster\u2011recovery strategy, and you will be in a far better position when something unexpected happens. If you are planning a new project or considering a migration, feel free to compare our published SLAs and blog resources\u2014for example, our guides on uptime, monitoring, backups and IPv4 planning\u2014to your current setup. And if you are unsure how a particular clause translates to real\u2011world risk for your website or application, reach out to our support team; we are happy to walk through it with you in plain language.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Most people sign up for hosting by comparing disk space, bandwidth and price, then scroll past the SLA and terms as fast as possible. Months later, a short outage or a resource limit kicks in, and that same fine print suddenly becomes very important. If you run an e\u2011commerce store, agency portfolio, SaaS app or [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3957,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3956","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3956","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3956"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3956\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3957"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3956"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3956"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3956"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}