Hosting SLA Checklist in 2026: What to Demand From Your Host

You can move a website in an afternoon. Climbing out of an outage while your host ignores tickets can take weeks. A hosting SLA checklist forces the conversation before you buy: what’s actually guaranteed, what’s “best effort,” and what the provider will do when things break.

At Hostperl, we see the same pattern during migrations. People upgrade for speed, then discover the real value is clarity: who covers support, who owns backups, and who is responsible for DNS, email, and security updates. This guide gives you a practical, buyer-focused checklist for 2026 that works for shared hosting, a VPS, or a dedicated server.

Why a hosting SLA checklist saves you money (and sleep)

An SLA isn’t just an uptime percentage. It’s a promise about what happens at 2am when checkout fails, the mail queue backs up, or an IP gets blocklisted. Without a checklist, most buyers compare price and specs, then get surprised by the expensive parts:

• Downtime you can’t escalate because support is “business hours only” in the wrong timezone.
• Backups that exist but can’t be restored—or don’t include what you assumed was covered.
• Email problems where “we don’t support mail” turns into missed quotes and unpaid invoices.
• Migrations that stall because DNS wasn’t planned, SSL wasn’t reissued, or the old host rate-limits exports.

In New Zealand and wider APAC, timezone coverage isn’t a detail—it’s the difference between a quick fix and a lost day. If your customers are active during NZ business hours, you want response targets that match those hours, written in plain terms.

Hosting SLA checklist: uptime, maintenance, and incident handling

Start with availability, then pin down what the headline number means in practice.

1) Uptime definition (what counts as “down”)

• Is uptime measured at network, hypervisor, or service level? “Network up” doesn’t mean “your website works”.
• Are control panel outages counted? cPanel/Plesk downtime can block email, SSL renewals, and DNS edits.
• What’s excluded? Planned maintenance, upstream DDoS, customer misconfiguration—get exclusions in writing.

Operational tip: Ask for one recent incident report example. If they can’t share a redacted summary (timeline, cause, corrective actions), treat the “SLA” as marketing, not operations.

2) Planned maintenance windows

• How much notice? You need enough time to plan releases and client comms.
• When do they schedule work? A competent provider avoids peak time for your region.
• What changes during maintenance? Kernel updates, hypervisor upgrades, storage work—each carries different risk.

If you run client sites, match maintenance to your workflow. For many agencies, a VPS is simpler than shared hosting because you control patch timing and can stage changes safely. Hostperl’s Hostperl VPS plans are often used by NZ agencies for that reason: predictable operations and straightforward upgrades.

3) Incident response and communication

• Status page: Is there a public status page, and do they post updates during an incident?
• Update cadence: “Regular updates” should become “every 30–60 minutes during active incidents”.
• Escalation path: Can your ticket reach on-call engineering, and what triggers escalation?

You’re looking for accountability: quick acknowledgement, time-boxed investigation, and a clear promise for the next update. If you have to chase, you’re already losing.

Support SLA: response times, scope, and what “managed” really means

Support is where hosting goes wrong most often. Usually it’s not bad intent—just mismatched expectations that nobody wrote down.

4) Response time targets by severity

A useful SLA separates issues by severity. A reasonable baseline in 2026 looks like this (providers will vary):

• Severity 1 (site down / email down): response target in minutes, not hours.
• Severity 2 (performance degradation): response target within a few hours.
• Severity 3 (how-to / minor config): response within a business day.

Ask: Are these targets 24/7, or only during local business hours? If your revenue is 24/7, “next business day” is not coverage.

5) Support channels that match real incidents

• Ticketing works for most requests, but ask how they handle major incidents.
• Phone/urgent channel matters when DNS or a domain breaks and you need coordinated action fast.
• Account-level contacts help agencies managing multiple client services and renewals.

6) Support scope: OS, control panel, app, email

Write the scope in plain English, then confirm it matches what you’re buying:

• Shared hosting: the host should own the full stack (web, PHP, mail, DNS platform, backups).
• VPS: clarify what’s included—OS patching? control panel updates? malware cleanup?
• Dedicated servers: confirm whether it’s unmanaged hardware only, or includes OS and panel care.

If you’re using cPanel/Plesk/DirectAdmin, get clarity on licensing and who is responsible for updates and renewals. This internal reference can help you ask better questions: VPS control panel licensing in 2026.

Backup & restore SLA: the part people only read after a crisis

Backups aren’t “set and forget.” Focus your checklist on two things: recoverability and recovery time.

7) What is backed up (and what is not)

• Files + databases: confirm both, and confirm frequency.
• Email: many plans exclude mailboxes or keep short retention. Don’t assume.
• Control panel config: DNS zones, SSL keys, cron jobs, mail routing—these are painful to rebuild.

8) Retention and storage separation

• Retention: 7 days is common; 14–30 days is safer for slow-detected issues.
• Separation: backups should be stored off-server (different storage system, ideally different failure domain).
• Immutable options: ask if they offer immutability or snapshot protection against ransomware-style deletion.

9) Restore process: who can do it, how fast, and how often

Ask direct questions and insist on direct answers:

• Self-serve restore? Many control panels allow partial restores. That matters at 9am on a Monday.
• RTO/RPO targets: how long to restore (RTO) and how much data you could lose (RPO).
• Test restores: do they test backups, and can you request a test restore quarterly?

If you operate from Plesk, scheduled backups are a solid baseline. This guide shows what “good” looks like in practice: Plesk website backup scheduling.

Email SLA: deliverability, queues, and the uncomfortable truth

Email is where “hosting” turns into reputation management. The uncomfortable truth: nobody can guarantee inbox placement. A sensible SLA can still cover what’s controllable—service availability, correct authentication, and monitoring.

10) Availability of email services

• IMAP/POP/SMTP uptime: confirm it’s included in uptime commitments if email is part of your plan.
• Mailbox limits: size caps and message-per-hour caps should be explicit to prevent surprise throttling.

11) Deliverability responsibilities (SPF/DKIM/DMARC)

Spell out who does what:

• Host provides DKIM keys and signing (or guides you if you self-manage).
• You control DNS (or the host manages DNS for you), because SPF/DMARC live in DNS.
• Blocklist support: what happens if an IP is listed? Do they help you remediate?

If you’re on cPanel, this is a common real-world support path: fix SPF, DKIM & DMARC in cPanel.

12) Queue monitoring and outbound controls

Busy sites create busy mail systems: order confirmations, form submissions, newsletter tools, password resets. Make sure your SLA covers:

• Queue visibility: can you (or support) see if mail is stuck?
• Abuse controls: what happens if a contact form is exploited and sends thousands of emails?
• Clear remediation: do they pause outbound, notify you, and help you clean up?

For cPanel users, queue handling is an operations issue, not a theory exercise: cPanel email queue management for busy hosting.

Migration SLA: timelines, responsibility, and what “free migration” should include

Migrations usually fail for boring, predictable reasons. DNS isn’t planned. Mailboxes aren’t mapped. Cutover lands in the middle of a busy workday. Your checklist should force a defined scope and a real plan.

13) What gets migrated

• Web content: files, databases, and permissions.
• Email: mailboxes, forwarders, autoresponders, and existing mail content (if included).
• DNS: zone records, TTL planning, and verification steps.
• SSL: reissue or transfer, including intermediate chain correctness.

14) Cutover plan and rollback

A good provider brings up rollback without being prompted. Your checklist should include:

• TTL adjustments: lowering TTL 24–48 hours before cutover for faster propagation.
• Freeze window: a short period where content changes pause (or are carefully synchronized).
• Rollback trigger: what conditions cause rollback, and who decides.

If you want a clear picture of what a migration service should include, this internal article sets expectations: Hosting migration service: what to expect (and request) in 2026.

Performance SLA: what’s reasonable to ask, and what isn’t

No host can promise “your site will be fast” without knowing your code, plugins, images, and traffic profile. You can still insist on measurable fundamentals: resources, storage, and how they handle contention.

15) Resource guarantees and noisy-neighbour policies

• Shared hosting: ask how CPU and memory contention is controlled, and what happens when one account misbehaves.
• VPS: confirm vCPU/RAM allocation and whether storage is NVMe-backed.
• Dedicated: verify disk type, RAID, and replacement process for failed drives.

As you grow, the right plan depends on how much variability you can tolerate. If you’re unsure where shared ends and VPS begins, this comparison helps: VPS vs shared hosting for growing sites.

16) Latency and region fit (NZ/APAC reality)

If your customers are in New Zealand or Australia, the route your traffic takes matters. You can’t SLA the public internet, but you can ask the questions that actually affect outcomes:

• Where is the server physically located?
• Do they offer APAC-friendly routing and peering?
• Do they provide tools to measure latency? (or will support help interpret results)

If you’ve ever heard “it’s slow from Wellington but fine from overseas,” you already know why region fit belongs in your selection process.

Security & access SLA: the boring clauses that prevent expensive mistakes

Hosting security is mostly process. Focus on access control, patch ownership, and auditability.

17) Access control and authentication

• 2FA availability for control panels and customer portals.
• Role-based access if you have staff or contractors (especially agencies).
• SSH policy on VPS/dedicated: key-based access, root login rules, and account handover procedures.

18) Patch responsibilities

• Shared hosting: host should patch OS and core services.
• VPS/dedicated: clarify if patching is your job, the host’s job, or shared responsibility.
• Control panel updates: confirm whether cPanel/Plesk/DirectAdmin updates are applied automatically and when.

19) Abuse handling and compromised account process

Compromises happen. The difference is how the provider responds and how quickly you regain control:

• Notification timeline: how quickly you’ll be told about malware, spam, or unusual traffic.
• Containment: do they isolate the account/server to protect other customers?
• Remediation support: do they help you clean up, or only suspend and send a link?

Billing & contract SLA: refunds, credits, and upgrade paths

This isn’t exciting, but it’s where arguments start.

20) Credit policy that matches your risk

• Service credits: are they automatic or only on request? What proof is required?
• Refunds: are setup fees refundable? What about control panel licenses?
• Exclusions: understand what doesn’t qualify (common: customer-caused downtime).

21) Upgrade and downgrade mechanics

• Can you scale without a full rebuild? This matters for busy seasons and campaign spikes.
• Do you keep the same IP? Important for DNS, email reputation, and API allowlists.
• What’s the lead time? Dedicated server upgrades often require scheduling.

For many Hostperl customers, the cleanest operational path looks like this: start on shared hosting, move to VPS when you need consistent resources, then graduate to dedicated when you need isolation and predictable performance under load. If you’re weighing VPS vs dedicated now, this is a useful decision aid: VPS vs dedicated server for hosting in 2026.

A practical way to use this checklist during vendor selection

You don’t need a 40-email procurement chain. Keep it tight and observable:

1. Send your top 10 checklist questions to sales/support before you pay.
2. Read how they answer: clear scope and timelines, or vague hedging?
3. Ask for one example of a recent incident postmortem or customer-facing update.
4. Decide what you will own (DNS, backups, patching) and what you expect the host to own.

Then pick the plan that fits how you operate—not just what your traffic looks like this month.

Summary: choose the host you can work with under pressure

A hosting SLA is less about legal wording and more about predictable behavior: how fast you’ll get a response, how restores are handled, how incidents are communicated, and whether migrations run like a project instead of a gamble.

If you want a platform that fits real SMB and agency operations in NZ/APAC—clear support expectations, practical migration help, and room to scale—start with Hostperl shared hosting for straightforward sites, or move to a managed VPS hosting plan when you need consistent resources and cleaner change control.

FAQ

Does a hosting SLA guarantee my website will be fast?

No. It can guarantee platform availability and response expectations, but your code, images, plugins, and caching still drive much of performance. Use the SLA to lock down what the host controls: resource allocation, storage type, and incident response.

What’s a reasonable uptime target for hosting in 2026?

Many providers advertise 99.9%+ uptime, but the number alone doesn’t tell you much. Ask how it’s measured, what’s excluded, and what compensation applies. Also confirm how they communicate during incidents, not just after.

Should email be covered in the SLA if I host email with my website?

Yes. At minimum, confirm availability commitments for SMTP/IMAP and the support scope for authentication records (SPF/DKIM/DMARC) and queue issues. Email is operationally critical even for small businesses.

Do I need an SLA on shared hosting?

If your site supports bookings, payments, or lead capture, yes. Shared hosting can be a good fit, but you still need clarity on backups, support response, and what happens during abuse or resource contention.

What should I ask about migrations in the SLA?

Scope (web, database, mail, DNS, SSL), a cutover plan with TTL guidance, a rollback approach, and who is responsible for testing after cutover. If a provider can’t explain the plan simply, expect surprises.