Service Level Agreement and Service Level Objective

This Service Level Agreement (SLA) and Service Level Objective (SLO) describe the service levels at which the services will be provided and the service level objective for response to technical tickets. The terms and conditions set forth here, which may be amended from time to time at Provider’s sole discretion, are hereby incorporated into each Order executed by the Provider and the Customer (each, an “Order”), pursuant to the terms below for the applicable service.

Section 1 Definitions. 
1.1    “Account Management Application” is the primary resource for Customers to access and manage information including, but not limited to, account profile, contact management, contracts, service and maintenance status of services and regions, and support tickets.
1.2    “Allocated Monthly Recurring Charge” or “Allocated MRC” shall mean the amount that the Provider automatically charges the Customer each month for the specific services provided as specified on the Order
1.3    “Availability” of the Provider’s Infrastructure shall be measured in the percentage of time during a particular month that the Customer’s service is accessible, excluding periods of Scheduled Maintenance. Unless specified on the Order as a Provider provided Connectivity Service, it shall exclude any public Internet Service Providers (ISPs) ability to provide consistent or stable network access from the Customer premise to the Provider’s Infrastructure.
1.4    “Customer Premises Equipment” or “CPE” is any terminal and associated equipment connected to the Provider’s telecommunication circuit at the Demarcation Point. It could be either provided by the Customer or by the Provider, as specified on the Order.
1.5    “Demarcation Point” or “Demarc” is a point established in a building or complex to separate CPE from the equipment located in either the distribution infrastructure or central office of the Provider.
1.6    “Provider’s Infrastructure” shall mean the compute, storage, switching, and network equipment owned and maintained by the Provider used to deliver the services to the Customer as specified in the Order; this includes underlying carrier infrastructure when the Provider provides Connectivity Services, as specified in the Order
1.7    “Outage” is the complete or partial failure of the Provider’s services. It shall be measured in hours from the time it has been detected, until the service has been fully restored, excluding periods of scheduled maintenance. During an Outage, the Provider’s services shall be deemed unavailable.

Section 2 Infrastructure and Service Availability SLA.  The Provider shall use commercially reasonable efforts to make sure that the services and resources described in an Order to which such Provider is a party are available each calendar month according to the table below.

Bare Metal Infrastructure 100%
Colocation 100%1
IaaS (Cloud and Secure Cloud) 100%
BaaS (Secure Cloud Backup) 100%
BaaS (Secure Cloud Backup for Microsoft 365) 100%
DRaaS (Secure Disaster Recovery as a Service) 100%
Secure Cloud Object Storage 100%
Connectivity Services – Lit Services 100%2
Connectivity Services – Dark Fiber 100%
Security Services 100%
1This Colocation availability SLA is exclusively applicable to the Provider’s Infrastructure and it applies only if the Customer provided equipment that supports dual power connected to redundant A+B power circuits.
2Applicable only for optical Wavelength and/or EPL (Ethernet Private Line) services. Excludes broadband services and unprotected circuits or other network hardware configured in a single architecture.

The Provider's Infrastructure will be deemed unavailable if (a) the Customer can neither transmit nor receive data to or from the Provider's Infrastructure (whereby inability is confirmed by way of Customer documentation that verifies said inability is due to an issue with the Provider’s equipment) and (b) such inability has been communicated to the Provider in sufficient detail to enable the Provider to open a case in respect thereof. The Provider's Infrastructure shall not be deemed unavailable (without limitation) in the event of any of the following:

2.1  Any circumstances whatsoever which are not within the reasonable control of Provider or its subcontractor(s);

2.2  Breach of the Agreement, the Services Schedule, the Order or this SLA and SLO by Customer;

2.3  Force Majeure events;

2.4  Virus activity and hacking attempts;

2.5  In accordance with a court order or any requirements of any authority or other competent local authority;

2.6  Periods of scheduled or emergency maintenance on Provider’s Infrastructure of which the Customer has been notified;

2.7  Failure or malfunction of the Customer’s or End-User’s connection to the Provider Network (e.g. via the public Internet or the Customer’s own network) or related problem beyond the Provider’s Network Demarcation Point

2.8  Failure or malfunction of equipment, software, or other technology not owned or controlled by Provider;

2.9  Failure to comply with any terms of Provider's then-current Acceptable Use Policy;

2.10  Failure or malfunction caused by Customer over-provisioning Reserved Resources in excess of the specifications set out on the Order;

2.11  A malfunction that results from inconsistencies in the environment or unavailability that result from changes in the Customer's source environment, including, but not limited to, either intentional or accidental connection or disconnections to the environment;

2.12  A malfunction that results from the negligence, or intentional acts or omissions of Customer or its employees, agents or any third party

2.13  A malfunction that results from anyone gaining access to the Cloud Resources by means of Customer’s passwords or equipment;

2.14  Any failure to restore an environment from a Cloud Backup file chain in the Provider’s cloud services (Secure Cloud Backup only); or

2.15  Unavailability of any management console or APIs.

The Provider, to the extent possible, will notify the Customer about scheduled or emergency maintenance through the Provider’s Account Management Application. The Provider will constantly update the Account Management Application information to advise the Customer when a maintenance is completed.

If during any calendar month, the Provider does not meet the service levels defined in Section 2 above, as Customer’s sole remedy and upon request, the Provider shall credit Customer the equivalent of one (1) hour fee for the applicable service for each hour of downtime during the month in which Provider fails to meet the SLA “Credit”). The one (1) hour fee is calculated as follows:

Allocated MRC for the affected service ÷ 720 hours = 1 hour fee

The Credits in this Section shall not apply to Provider Customers that have contracted with the Provider through a third party Reseller.

For remedy calculation purposes, downtime from an Outage starts from the time that the service’s unavailability is reported to the Provider by the Customer and ends when the Provider restores the service. All billing credits are applied at the end of the billing cycle during which the notification of failure was received.

The following conditions must be met to be eligible for Billing Credits:

3.1  A Credit shall be applicable and issued only if the aggregate amount of Credits for the applicable monthly billing cycle is greater than ten dollars ($10 USD). Service Credits may not be transferred or applied to any other account.

3.2  In order to request a Credit, the Customer must contact the Provider within thirty (30) days from the last day of the reported event by emailing [email protected] and provide reasonably sufficient information in the email for the Provider to determine whether a Credit is warranted, including, but not limited to, the ticket number that was raised by the Customer in relation to the corresponding incident. Failure of the Customer to follow the procedure in the preceding sentence shall waive the Customer’s ability to receive a Credit for the affected period.

3.3  Provider shall use all information reasonably available to it to validate Claims and make a good faith judgment on whether the Customer is entitled to Credits under this Section.

3.4  Provider shall only apply Credit against future payments otherwise due from the Customer and are not transferable or redeemable for cash. The Customer's sole and exclusive remedy, and the Provider's sole liability, with respect to Provider's breach of its obligations of this Service Level Agreement are Credits as described in Section 3.

3.5  The Customer shall not be entitled to any Credit if the account is delinquent or Customer has otherwise breached the Agreement, Services Schedule, Order or this SLA. If failure occurred as a result of Customer’s misuse, deliberate, or unintentional action outside of the Acceptable Usage, Customer is not entitled to Service Credits.

Section 4 Technical Ticket Response SLO The Provider shall use commercially reasonable efforts to make sure that the Technical Ticket Response Management process adheres to the Targets set out in the chart below.
Initial Response Target
Severity 1
Production system down
  • A service is "down" or there is a critical impact to the customer's business operations.
< 15 mins
Severity 2
System impaired
  • The Customer's business has moderate loss or degradation of services and can reasonably continue in an impaired or restricted manner.
< 30 mins
Severity 3
General guidance
  • The Customer has a general question or need help using a Provider's product/service.
< 24 business hrs
Change request*
  • Customer submitted change request (e.g., new system addition, new replication job request, new VLAN configuration at the designated Provider’s Recovery Site).
< 8 business hrs
*The Initial Response Target for change requests shall only apply to the Provider’s services that explicitly support Provider’s adds, changes, and disconnection as part of the service. Depending on the nature of the request, if not supported by the underlying service, the Provider may assess a one-time, non-recurring fee for any changes.

Section 5 Service Performance SLO. 

5.1  Cloud Storage

5.1.1  Storage Performance Target.The Provider shall offer different storage types with targeted performance according to the following chart.

Storage Type
Average Performance
Average Response Time Target (Read/Write)
Advanced/Accelerated Storage 500 IOPS per TB 5 ms (millisecond)
SSD Storage 2000 IOPS per TB 1 ms (millisecond)

5.1.2  Storage Performance Limits The storage is capable of very high IOPS, and that enables the Provider to allow Customers to occasionally burst IOPS over the guaranteed aggregated average IOPS for no additional charge. However, if the Provider determines, in its sole discretion, that the Customer's IOPS bursting is excessive or detrimental to overall storage performance, then, the Provider will notify the Customer about the excessive bursting and work with the Customer to: a) correct the issue causing the excessive bursting, or b) upgrade to the next available storage tier. If the Customer and Provider cannot come to a resolution within thirty (30) days after the notice, the Provider shall, at its sole discretion, rate limit such IOPS until the Customer can correct the issue causing the excessive bursting.

5.2  DRaaS

5.2.1  Recovery Time Objective (RTO). Once the Customer has completed a successful test of the then-current Recovery Plan with the Provider’s involvement, the Provider shall use commercially reasonable efforts to ensure that Failover occurs at the average rate of 1 Virtual Machine per minute; considering that the following contributing factors may impact it:

  1. Applicable to Recovery Groups of Virtual Machines in increments of 100. Less Virtual Machines could result in longer Failover times;
  2. Journal size (specific to Zerto environments);
  3. Failing over in sequence versus bulk;
  4. The point in time being used when failing over;
  5. Excluding boot-up time, and specifically tracking when the Virtual Machine is in a powered-on state;
  6. The breach of this average RTO does not qualify for Billing Credits; and
  7. For Customers with a managed service, this RTO would be superseded by the success criteria after the initial recovery test where the Provider and Customer would, in good faith, mutually agree on the service level commitments for the services to be performed during the remaining term of the contract. This agreed RTO would be applicable only for the latest Point-In-Time (PIT) snapshot.

5.2.2  Recovery Point Objective (RPO). Customer's RPO is determined and reflected based on settings in the replication engine software, and, as a result, the Provider can only offer guarantee on best efforts in assisting Customer to achieve that RPO dependent on Customer’s bandwidth and configuration.
Recovery Time Objective (RTO) Average of 1 Virtual Machine per Minute (see above)
Recovery Point Objective (RPO) Based on Recovery Group settings