Last updated: September 19, 2023
This Service Level Agreement (“SLA”) applies to the use of the Redis (“Redis” “us” or “we”) Redis Enterprise Cloud Services (“Cloud Services”), offered under the terms of our Cloud Terms of Service or other agreement with us governing Customer’s use of Redis Products and Services (the “Agreement”). It is clarified that this SLA is part of and subject to the terms of the Agreement, and capitalized terms, unless otherwise indicated herein, have the meaning specified in the Agreement. Redis reserves the right to change the terms of this SLA by publishing updated terms on its website, such change to be effective as of the date of publication.
“Active-Active SLA” applies to Active-Active database deployments.
“Deployment Minutes” is the total number of minutes that a given database has been deployed with the Cloud Services during a billing month.
“Downtime” is the total accumulated Deployment Minutes (across all databases deployed by a Customer in a given Cloud Services subscription) during which the database is unavailable. A minute is considered unavailable for a given database if all continuous attempts by a Customer to establish a connection to the Redis Enterprise Cloud database within that minute fail. However, for Active-Active SLAs, a minute is considered unavailable if all continuous attempts by a Customer to establish a connection to all the Redis Enterprise Cloud databases under Active-Active deployment within that minute fail. Furthermore, “Downtime” does not include downtime for Maintenance. Additionally, partial minutes of unavailability will not be counted towards Downtime.
“Maintenance” is the incorporation of new features, upgrades, updates, cluster optimization, patches, and/or bug fixes performed on the Cloud Services.
“Maximum Available Minutes” is the sum of all Deployment Minutes across all databases deployed by a Customer in a given Cloud Services subscription during a billing month.
“Monthly Uptime Percentage” for a database is calculated as the Maximum Available Minutes less Downtime divided by Maximum Available Minutes in a billing month for a given Cloud Services subscription. This Monthly Uptime Percentage is represented by the following formula:
“Multi-AZ SLA” applies to Multi-AZ database deployments that are not part of an Active-Active deployment.
“Shard” means a billing unit that supports a certain dataset size (in GBs) at a certain throughput (in ops/sec) as described in the Documentation. Shards are used to size Customer’s Workload (as defined below).
“Service Credit” is a credit or discount toward future Cloud Services and is Customer’s sole and exclusive remedy for any failure by Redis to provide Cloud Services in compliance with the Service Commitment or any other representation or warranty related to the Cloud Services.
“Standard SLA” applies to Standard database deployments that are not part of an Active-Active deployment, or a Multi-AZ deployment. This is the only level of Monthly Uptime Percentage applicable to fixed plans.
These Service Commitments and Service Credits apply only to Cloud Service deployments with replication enabled that have been up for a minimum of 24 hours, and apply separately to each Commercial Subscription of the Cloud Services. Redis will use commercially reasonable efforts to maximize the availability of its Cloud Services, and provide Monthly Uptime Percentages of (a) at least 99.999% if the Active-Active SLA applies; (b) at least 99.99% if the Multi-AZ SLA applies; or (c) at least 99.9% if the Standard SLA applies (this entails our “Service Commitment”). In the event Cloud Services do not meet this Service Commitment, Customer will be eligible to receive a Service Credit as described below.
Redis provides the Cloud Services in three paid plans: (i) fixed, (ii) flexible, and (iii) annual. The plan Customer selects affects Customer’s fees, Transaction method, Maintenance Window permissions, Monthly Uptime Percentage, infrastructure configuration, etc. as described here: https://redis.com/redis-enterprise-cloud/pricing/.
Redis utilizes capacity and throughput measurement standards to assist Customer with the configuration of the Cloud Services as described in the Documentation based on typical usage (the “Reference Workload”). Redis will use commercially reasonable efforts to provision Customer with sufficient Cloud Services resources that Redis determines are typical based on the Reference Workload relative to Customer’s requested capacity and throughput (the “Provisioned Workload”). However, the actual volume of data being uploaded or retrieved from the Cloud Services along with the complexity of the commands executed by Customer within the Cloud Services determines the actual performance of the Cloud Services (the “Actual Workload”). If Customer consistently utilizes commands which are significantly more CPU intensive, consistently generates significantly larger response sizes, or consistently include significantly larger payload sizes than the Reference Workload, it is possible that the Provisioned Workload will not be able to satisfy the Actual Workload. In such event, Customer may need to increase the Provisioned Workload in order for Redis to provide sufficient resources to meet Customer’s Actual Workload. Redis will notify Customer if its selected plan and Provisioned Workload are insufficient for the transfer volumes and observed command mix generated by Customer in the Cloud Services. The Provisioned Workload options of fixed plans are limited, and Redis may slow or block data transfers if Customer’s Actual Workload causes excessive congestion or network charges. Flexible and annual plans of the Cloud Services are not subject to slowing or blocking by Redis.
If Customer’s Provisioned Workload is unable to consistently meet the levels of the Actual Workload, Redis will work with Customer to adjust Provisioned Workload to maintain the operational stability of the Cloud Services. From the date of that communication, Customer has 2 weeks (a “Grace Period”) during which Redis will support Customer’s Actual Workload and reasonable excessive usage of the Cloud Services at no additional charge. During the Grace Period, Redis will work with Customer to determine whether optimization of the Cloud Services is possible for Customer’s Actual Workload or whether an increase of the Provisioned Workload to meet the desired performance of the Cloud Services is necessary. After the Grace Period, Redis may modify the Provisioned Workload to ensure operational stability of the Cloud Service and additional fees may apply. If Customer has more than 2 Grace Periods in any 6-month calendar period, Redis reserves the right to require reasonable adjustments to the Provisioned Workload in order to meet the applicable SLA.
Service Credits are calculated as a percentage of the monthly charges paid by Customer for a Cloud Services Commercial Subscription that did not meet the applicable Service Commitment in a billing cycle in accordance with the schedule below:
| Monthly Uptime Percentage | Service Credit Percentage | |
|---|---|---|
| Active-Active SLA | Less than 99.999%, but equal to or greater than 99% — Less than 99% | 10% — 25% |
| Multi-AZ SLA | Less than 99.99%, but equal to or greater than 99% — Less than 99% | 10% — 25% |
| Standard SLA | Less than 99.9%, but equal to or greater than 99% — Less than 99% | 10% — 25% |
Redis will only apply Service Credits against future payments for Cloud Services. At our discretion, Redis may issue Service Credits to the Payment Method Customer used to pay for the billing cycle in which the failure to meet the Service Commitment occurred. Service Credits will not entitle Customer to any refund or other payment from Redis. Service Credits may not be transferred or applied to any other account. Unless otherwise indicated in the Agreement, Customer’s sole and exclusive remedy for any unavailability, non-performance or other failure by Redis to provide Cloud Services in compliance with the Service Commitment or any other Redis representation or warranty is the receipt of Service Credits (if eligible) in accordance with the terms of this SLA.
To receive a Service Credit, Customer must take all of the following actions: (1) log a support ticket with Redis within 24 hours of first becoming aware of an event that has impacted service availability, and (2) submit to Redis a credit request with respect to such event, including the information specified below and other related information which may be requested by Redis, by the end of the second billing cycle after which the incident occurred. For example, if the Downtime occurred on February 15th, we must receive a support ticket within 24 hours of Customer becoming aware of such Downtime, and receive a credit request including all required information by March 31st. The credit request must include:
If the Monthly Uptime Percentage of such credit request is confirmed by Redis and is less than the Service Commitment, we will issue the Service Credits to Customer within one billing cycle following the month in which the credit request occurred. Failure to provide the credit request and other required information above will disqualify Customer from receiving Service Credits. Furthermore, Customer must be in compliance with the Agreement in order to be eligible for a Service Credit and will otherwise not be entitled, even if all other requirements hereunder are met.
Notwithstanding anything to the contrary herein, this SLA does not apply to any performance or availability issues (and such will not count towards any Downtime calculation):
If availability is impacted by factors other than those explicitly used in our Monthly Uptime Percentage calculation, then Redis may at our sole discretion, decide to regardless consider such factors and issue a corresponding Service Credit. Cloud Services based on older versions will be completely terminated and unavailable 18 months after an upgrade or as announced by Redis.
These Maintenance and Maintenance Window terms apply to all Commercial Subscriptions of the Cloud Services. Redis may perform Maintenance at any time. Notwithstanding the foregoing, Customers with annual or flexible plans are encouraged to manually select a standard weekly period for Maintenance within a Redis user interface (each, a weekly “Maintenance Window”). Despite the selection of a weekly Maintenance Window, Redis won’t necessarily perform Maintenance every week. Customers who select a Maintenance Window may postpone a Maintenance Window no more than two-times in one month and no more than ten times in a calendar year via a Redis user interface. Maintenance Windows are not currently available for fixed plans. Redis will use best efforts to perform Maintenance within the designated Maintenance Window, however Customer acknowledges there is a chance Maintenance may require more time than anticipated and in such instances the Maintenance may complete outside the Maintenance Window.
If Customer declines to select a Maintenance Window, Redis may schedule and perform Maintenance at its sole discretion and will provide notice to Customer when Maintenance begins and when it ends. Redis may perform Maintenance within Customer’s selected Maintenance Window without advance notice, but will provide notice to Customer when Maintenance begins and when it ends. If upcoming Maintenance is a high impact event, at Redis’ sole discretion, Redis will provide reasonable advance notice to Customers with annual or flexible plans only. Redis will not provide Maintenance notice to Customers on fixed plans. Notwithstanding plan type or any Maintenance Windows selected, Redis reserves the right to perform urgent Maintenance activities as soon as they are needed.
If Customer-side actions are necessary in advance of Maintenance or in connection with Actual Workload analysis by the Parties during the Grace Period, Customer will be given notice and a reasonable amount of time to make the necessary modifications or actions in its deployment environment. If Customer fails to do so, the applicable Redis SLA will not apply after such Maintenance or Grace Period. Customer recognizes and agrees that Redis will not be liable for data or information loss of any kind, availability issues, security issues, or other related issues or damages that may have been mitigated or avoided by following Redis’ instructions in the Maintenance notice or during the Grace Period.
