We will do everything legally possible to help you succeed. Here is some of the info you need to keep things legal between us.
CloudKey Services
We offer 2 CloudKey Services:
– CloudKey with 2-Site Replication (“CloudKey 2SR”)
– CloudKey with 3-Site Replication (“CloudKey 3SR”)
Below are the comparisons between CloudKey 2SR and CloudKey 3SR:
| Description | CloudKey 2SR | CloudKey 3SR |
| Live Workload Replication Sites | 1 Primary + 1 Secondary | 1 Primary + 1 Secondary + 1 Tertiary |
| Distance between sites | 500 miles or greater | 500 miles or greater |
| Latency between sites | 70 ms or less | 70 ms or less |
| Live replication protocol | Site to site protected | Site to site protected |
| Live replication latency | 10 seconds or less | 10 seconds or less |
| Disaster Recovery Services (DRS) | Included* | Included* |
| Recovery Point Objective (RPO) | 2 hours or less* | 2 hours or less* |
| Recovery Time Objective (RTO) | 4 hours or less* | 4 hours or less* |
| Standard Snapshot Frequency | Every hour for the last 24 hours | Every hour for the last 24 hours |
| Standard Backup Frequency | One per day for the last 30 days on secondary site | One per day for the last 30 days on secondary or tertiary site |
Table 1
*See the Disaster Recovery Services section for details.
Disaster Recovery Services
Disaster Recovery Services (“DRS”) with hourly snapshots of each instance are included in CloudKey Services by default. In the event of a disaster or emergency, you can request a restoration of one or more instances via our support ticketing system. For security reasons, we will require you to provide us with the necessary information for each instance. All restoration requests will be addressed as soon as possible, with priority placed on the primary site, unless a site-wide disaster occurs. We aim to complete each instance restoration within 4 hours or less, or best effort depending on the size, the complexity, and the number of the instances that need to be restored. Our goal is for you to be made whole again as soon as possible with the latest viable live workload when a disaster strikes.
CloudKey 100% Uptime Guarantee
CloudKey offers a 100% uptime guarantee based on node (the infrastructure layer that hosts your instances or virtual machines) and network availability for our standard 2 Site Replication (“2SR”) and our ultimate 3 Site Replication (“3SR”) service offerings as part of the terms of the CloudKey Master Service Agreement.
The uptime guarantee ONLY applies to our CloudKey node and network availability during normal operation and does not apply to (a) DRS, (b) other add-on Services, or (c) your content or server-side software. Therefore, the following outage scenarios will not be covered by our guarantee: (a) any outage due to server software, operating systems, improper configurations, malware or ransomware, denial of service attack against your content or instance, (b) instance suspension, instance paused or halted for any reason, (c) third-party network outage not under our control, or (c) any other non-network or non-“host node” outage, for any reason and whether or not such outage is caused by us due to upgrading, troubleshooting, or performing any other tasks. The guarantee does NOT apply when a scheduled maintenance event occurs with a minimum of 24 hours’ notice or in the event a time-critical patch or update must be applied, as long as the outage or packet loss does not exceed 10 minutes. Outage caused by issues that are under our control will result in credit as defined on the table below:
| Outage in Minutes in a Month | Outage in Minutes in a Month |
| 1 – 10 | 24 hours |
| 11 – 60 | 48 hours |
| 61 – 120 | 96 hours |
| 121 – 240 | 192 hours |
| 241 – 480 | 384 hours |
| 480+ | 1 Full month |
Table 2
Furthermore, none of the guarantees in this SLA may be combined. For example, a hardware failure that causes network loss will not qualify you for two separate credits. If, for example, a hardware failure was the basis for the connectivity loss, the entire event will count as one single outage for the purpose of determining applicable credit.
Packet Loss and Latency
While we proactively monitor the aggregate packet loss and transmission latency within our LAN and WAN, we do not proactively monitor the packet loss or transmission latency of a specific network. In the event that a packet loss is discovered (either by us or after being reported by you) such that you are experiencing packet loss in excess of 1% or greater (“Excess Packet Loss”) between your instance and our switch or router, we will take all actions necessary to determine the source of the Excess Packet Loss. All notifications regarding packet loss and latency must be submitted in writing via the ticket system.
How to Obtain Credit
In order to receive any credit under this SLA, you must (a) initiate a support ticket related to the event, (b) provide detailed documentation on the instance(s) affected, and (c) expressly request the credit, and (d) your account is in good standing. We will then perform an analysis of the outage to determine the root cause of the outage. Outages related to issues caused by you or your End User, by a third party, or by an event that is not under our control are not eligible for any guarantee or credit offered under this SLA.