SLA options for Exponential hosting #

This page is for product managers and managers at a hosting company who write the service level agreement (SLA) of an Exponential hosting offer. It answers: which commitments are possible, what each one depends on, how you measure it, and what to exclude.

Contents #

1. What an SLA can cover
2. Each commitment and what it depends on
3. Measuring what you promise
4. Exclusions to state
5. An SLA template

What an SLA can cover #

Each commitment and what it depends on #

Availability #

Depends on the machine, the network, the engine and the database. Things in Exponential that help you keep it:

• Velocity can be guarded by an optional watchdog that starts the engine again after a crash (exp:velocity watchdog install, [WatchdogSettings] in settings/velocity.ini); see Velocity for hosts.
• Several web nodes behind a load balancer need a database server and shared storage (Several web nodes).
• Caches reduce the load a traffic spike causes (Caching layers).

Support response #

Depends on your staffing, not on the software. Define severities first (Support tiers), then times per severity.

Recovery point and recovery time #

Depend on the backup frequency, the backup method per database and the size of var/storage. The time of a restore is only known after you have done one: test it (Restore and restore tests).

Security updates #

Depend on how fast the project releases and how fast you apply. The project's side, from SECURITY.md: security fixes "are made on the main branch ... and published with the next 6.0.x release", and "a published tag is never changed". Your side: watching releases (Working with the project and 7x) and an update procedure (Upgrading customer sites).

Measuring what you promise #

Exclusions to state #

• the customer's own code, templates and extensions, and changes the customer made to the configuration;
• extensions not supplied by the host;
• outages caused by a customer's content (for example an import that fills the disk);
• planned maintenance in announced windows;
• third-party services the site calls (payment providers, mail, external APIs);
• force majeure, as your legal adviser words it.

An SLA template #

Service level agreement — <plan name>                 version <x>, valid from <date>

1. Availability        <percentage> per <month>, measured by <external check> on <URL>,
                       excluding announced maintenance windows.
2. Maintenance         windows <day/time, time zone>, announced <n> days ahead by <channel>.
3. Support             severities and first-response times as in the support tier sheet <tier name>.
4. Backups             <what> every <interval>; kept <n> days; stored <where>.
   RPO                 <time>.   RTO <time>, restore last tested on <date>.
5. Security updates    released Exponential security fixes applied within <time> of release;
                       PHP and OS security updates within <time>.
6. Exclusions          <list from this page>.
7. Credits             <your credit model, if any>.
8. Reporting           <monthly report: availability, incidents, restore tests>.

Related pages #

• Support tiers
• Designing hosting plans
• Health checks and uptime
• Backup schedules and retention
• Security updates and disclosure
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.