A Service Level Agreement is the document that separates a hosting provider's marketing claims from their actual commitments. It's the difference between a provider who says "we offer 24/7 support" and one who is legally bound to respond to a critical incident within fifteen minutes at any hour of the day or night.
Most businesses signing up for managed dedicated server hosting in India read their SLA the way most people read software terms and conditions — they don't. They skim the pricing page, have a reassuring chat with a sales representative, and sign up based on the impression they've been given rather than the commitments they've actually secured.
This is a mistake that tends to reveal itself at the worst possible time.
This article tells you exactly what your managed dedicated server SLA should contain, what weak or absent provisions look like, and when the right answer is to walk away and find a provider who takes their commitments seriously.
Why SLAs Matter More Than Sales Conversations
A sales representative's job is to make you feel confident enough to sign up. They are typically personable, knowledgeable, and genuinely helpful — but their words, no matter how reassuring, are not enforceable. The SLA is.
When your server goes down during your highest-traffic sales period, the relevant document is not the email thread where a sales rep said "our team is always available." It's the SLA that specifies whether "always available" means a fifteen-minute response or a four-hour one.
Read the SLA. All of it. If something important is missing or vague, ask for it in writing. If a provider can't or won't commit to specific terms, that tells you exactly how much their verbal assurances are worth.
SLA Requirement #1: Uptime Guarantee With Teeth
Any reputable managed dedicated server provider in India should offer a minimum of 99.9% uptime — and serious providers will commit to 99.95% or 99.99%. These percentages translate into very different amounts of acceptable downtime:
- 99.9% = up to 8.7 hours of downtime per year
- 99.95% = up to 4.4 hours per year
- 99.99% = up to 52 minutes per year
The percentage matters — but what matters even more is what happens when the provider misses it.
An SLA with an uptime guarantee but no consequences for breaching it is just a number on paper. Your SLA should specify service credits — automatic compensation in the form of account credits or fee reductions — triggered when uptime falls below the guaranteed threshold. The credit amount should be meaningful: a month of hosting credit for a few hours of downtime makes the guarantee real. A token 5% credit for an entire day of outage does not.
Watch for exclusions. Providers routinely carve out "scheduled maintenance," "force majeure events," and "issues outside our control" from their uptime calculations. Some of these exclusions are reasonable. Others are written broadly enough to cover circumstances that a properly engineered infrastructure should handle without any downtime at all.
SLA Requirement #2: Defined Response Times by Severity
"24/7 support" is one of the most meaningless phrases in hosting marketing. What it tells you is that someone can be contacted at any hour. What it doesn't tell you is how quickly they'll actually respond, or how quickly they'll resolve the problem.
Your SLA should define response and resolution times for different levels of incident severity. A framework that works:
Critical (server down, site completely unavailable): Response within 15 minutes. Resolution target within 2 hours.
High (severe performance degradation, major feature broken): Response within 30 minutes. Resolution target within 4 hours.
Medium (partial functionality affected, workaround available): Response within 2 hours. Resolution target within 8 hours.
Low (non-urgent question, minor issue): Response within 4–8 hours.
These are reasonable standards that top-tier Indian managed hosting providers meet. If your SLA defines "critical incident response" as four hours, or doesn't differentiate between a server being completely down and a billing question — keep looking.
Also check: does the SLA distinguish between response time (acknowledging your ticket) and resolution time (actually fixing the problem)? Some providers meet their response SLA by sending an automated "we've received your ticket" email and then taking six hours to assign a technician. That's not managed hosting. That's a ticketing system with a fast autoresponder.
SLA Requirement #3: Proactive Monitoring Commitments
A genuinely managed server should be monitored continuously, and your SLA should say so explicitly. Look for:
- Confirmation that monitoring runs 24 hours a day, 7 days a week
- Specification of what is monitored: CPU, memory, disk, network, service availability (HTTP, database, mail) — not just "server health"
- Commitment to alert thresholds: at what percentage of CPU or disk utilisation does your provider investigate?
- Statement that monitoring is proactive — meaning your provider identifies and responds to issues without waiting for you to raise a ticket
If the SLA only describes what happens after you contact support, it's describing a reactive service, not a managed one. Proactive monitoring is what separates managed hosting from a help desk with good hardware.
SLA Requirement #4: Security Patching Timeline
Software vulnerabilities are published daily. When a critical security vulnerability is disclosed for a widely-used component — the Linux kernel, OpenSSL, Apache, MySQL — the window between public disclosure and active exploitation can be hours or days, not weeks.
Your SLA should specify:
- That OS and core software security patches are applied as part of the managed service (not just available on request)
- A timeline for applying critical security patches: 24–48 hours from release is a reasonable industry standard for critical vulnerabilities
- That patch application includes testing where appropriate, to avoid a security fix breaking your application
Providers that don't commit to a patching timeline in writing are telling you that their patching is ad hoc — which means your server's vulnerability window is indefinite after a new exploit is published.
SLA Requirement #5: Backup Frequency, Retention, and Recovery Time
Backups are only worth having if they work when you need them. Your SLA should specify:
Frequency: How often are backups taken? Daily is a minimum. For database-heavy applications, more frequent incremental backups are strongly preferable.
Retention: How long are backups kept? A minimum of 7 days of daily backups, with at least 4 weeks of weekly backups, gives you meaningful recovery options for different types of incidents.
Storage location: Are backups stored separately from the primary server? A backup on the same physical machine (or even the same data centre) offers no protection against a facility-level event.
Recovery Time Objective (RTO): How long will it take to restore your server from backup if needed? This should be a committed timeframe, not "we'll do our best."
Backup verification: Does the provider test that backups are actually recoverable? This is the most important question, and the one most providers answer vaguely. Push for specifics.
A backup SLA that doesn't include recovery time commitments and verification testing is half an SLA. Untested backups are a liability, not an asset.
SLA Requirement #6: Hardware Failure Response
Physical hardware fails. Hard drives, memory modules, network interface cards, power supplies — all of them have finite lifespans, and all of them will eventually fail in a production environment.
Your SLA should specify:
- Detection: How quickly will a hardware failure be identified? Ideally, through proactive monitoring rather than a customer complaint.
- Replacement timeline: What is the committed time to replace a failed component? For critical components like storage, 2–4 hours is a standard commitment in Tier III and Tier IV data centres.
- Data integrity: In the event of storage failure, what is the provider's commitment regarding data recovery?
Without a hardware SLA, "dedicated server" hosting can become "shared downtime" very quickly. Hardware issues are not rare enough to leave unaddressed in your contract.
SLA Requirement #7: DDoS Mitigation Specifics
"DDoS protection included" is another phrase that ranges from genuinely robust to essentially meaningless, depending on what it actually covers.
Your SLA should specify:
- Mitigation capacity: What size of attack (in Gbps) can the provider absorb and scrub? 10 Gbps is a bare minimum for serious protection. Enterprise-grade protection often reaches hundreds of Gbps.
- Activation: Is mitigation automatic (triggered within seconds of attack detection) or manual (requiring your provider to configure it after you report an attack)?
- Scrubbing vs. null-routing: Scrubbing filters malicious traffic and passes clean traffic to your server, keeping you online. Null-routing blocks all traffic to your IP, taking you offline. These are very different outcomes — know which one your provider offers.
- Duration: Is there a time limit on DDoS mitigation? Some providers null-route servers after a sustained attack exceeds a threshold.
In India's threat environment, DDoS attacks against business infrastructure are a genuine daily occurrence. Vague DDoS protection that turns out to mean "we'll block your IP and wait for the attack to stop" is not protection — it's managed downtime.
SLA Requirement #8: Termination and Data Portability
This one is often overlooked until a business wants to leave a provider, at which point it becomes very important very quickly.
Your SLA should specify:
- Notice period: How much advance notice does either party need to give to terminate the contract? For a managed server hosting business-critical infrastructure, thirty days is a reasonable minimum.
- Data return: What is the process for receiving your data upon termination? Is there a committed timeline for providing it?
- Migration assistance: Does the provider offer assistance with migrating your data and configuration to a new provider?
- Post-termination data deletion: When and how is your data deleted from the provider's systems after termination?
A provider confident in their service quality will not bury the termination terms in punitive fine print. Contracts that make it very difficult to leave are often designed to compensate for service quality that would otherwise cause customers to leave.
Red Flags in SLA Language
As you read your SLA, watch for these patterns:
"Commercially reasonable efforts" — This phrase, used in place of specific commitments, means your provider will try but has made no quantified promise. It's legally meaningless from a customer perspective.
Extremely broad force majeure clauses — Force majeure ("acts of God") exclusions are reasonable for genuine unforeseeable events. But some providers write them broadly enough to cover events that proper infrastructure engineering should handle without incident.
Response time commitments that only apply during business hours — For managed hosting, business hours support is simply not managed hosting. Critical incident response must be 24/7.
Credits as the sole remedy — Service credits are appropriate compensation for minor SLA breaches. If the only remedy available to you for a catastrophic, extended outage is a credit equivalent to a few days of hosting fees, your SLA is not balanced in your favour.
Unilateral amendment rights — Some providers reserve the right to change SLA terms with minimal notice. This is a significant risk for businesses that have built operational dependencies on committed service levels.
The SLA Conversation to Have Before You Sign
Before committing to any managed dedicated server provider in India, ask them to walk you through their SLA on a call. Specifically:
"Can you show me exactly where in the SLA it commits to critical incident response time?"
"What service credits am I entitled to if you miss your uptime guarantee?"
"How is your DDoS protection implemented — scrubbing or null-routing?"
"What's the process if I want to leave and take my data with me?"
The quality and specificity of the answers — and how quickly and confidently the provider can point you to the relevant clauses — tells you more about the reliability of the service than any case study or testimonial.
A provider who has built infrastructure and processes they're genuinely proud of will be delighted to walk you through the SLA. One who becomes vague or evasive when the conversation gets specific is telling you something important.
Listen to it.
