Redis Cloud Service Level Agreement (SLA)

Last updated: March 15, 2024

This Service Level Agreement (“SLA”) applies to the use of the Redis Enterprise Cloud Services (“Cloud Services”), offered under the terms of the Cloud Terms of Service or other agreement with us governing Customer’s use of Redis Cloud and Services (the “Agreement”). 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. 

1. Definitions

“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 under a Commercial Subscription) during which the Database is unavailable. A minute is considered unavailable for a Database if all continuous attempts by a Customer to establish a connection to the 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 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:

Monthly Uptime % = (Maximum Available Minutes – Downtime) / Maximum Available Minutes

“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 essential plans. 

2. Cloud Services Plans and Configuration. 

2.1 Plans. Redis provides the Cloud Services in thr ee paid plans: (i) essentials, (ii) pro, and (iii) annual. The plan Customer selects affects Customer’s fees, Transaction method, Maintenance Window permissions, Monthly Uptime Percentage, infrastructure configuration, Cloud Services limits (if applicable), etc. as described here: https://redis.io/pricing/#cloud. 

2.2 Configuration and Performance. 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 essentials and pro plans are subject to limits, and Redis may slow or block data transfers if a Customer’s Actual Workload causes excessive congestion, reaches the applicable limits, or excess charges (“Workload Restrictions”). Redis is not liable for any performance issues related to Workload Restrictions. Annual plans of the Cloud Services are not subject to slowing or blocking by Redis. 

2.3 Grace Period. 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.

3. Service Levels and Remedies. 

3.1 Service Commitments. The 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 under a Transaction 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 (the applicable “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.

3.2 Service Credits. 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 Table 1 – Service Credit Calculations:

Table 1 – Service Credit Calculations

Description	Monthly Uptime Percentage	Service Credit Percentage
Active-Active SLA	Less than 99.999%, but equal to or greater than 99%	10%
	Less than 99%	25%
Multi-AZ SLA	Less than 99.99%, but equal to or greater than 99%	10%
	Less than 99%	25%
Standard SLA	Less than 99.9%, but equal to or greater than 99%	10%
	Less than 99%	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.

3.3 Service Credit Request and Payment Procedures. To receive a Service Credit, Customer must take all of the following actions: (a) log a support ticket with Redis within 24 hours of first becoming aware of an event that has impacted service availability; and (b) submit to Redis a 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, Redis must receive a support ticket within 24 hours of Customer becoming aware of such Downtime, and receive a request including all required information by March 31^st. The Service Credit request must include:

1. The words “SLA Credit Request” in the subject line;
2. The dates and times of each Downtime incident Customer are claiming;
3. The Database(s) name, the cloud(s) name and regions of the affected Database;
4. Logs that document the errors and corroborate Customer’s claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks); and
5. Descriptions of Customer’s attempts to resolve the events resulting in Downtime at the time of occurrence. Customer must reasonably assist Redis with any problem diagnosis and resolution.

If the Monthly Uptime Percentage of such Service Credit request is confirmed by Redis and is less than the Service Commitment, Redis will issue the Service Credits to Customer within one billing cycle following the month in which the credit request was received by Redis. Failure to provide the Service Credit request and other required information above disqualifies 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.

4. SLA Exclusions. 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):

1. That result from a suspension described in the Agreement;
2. Related to Free Services or Preview deployments;
3. That result from any voluntary actions or inactions from Customer or any third party (e.g., rebooting, shutting down, or any access to a Database Instance that is part of Redis Enterprise Cluster; if the Cloud Services are deployed on Customer’s VPC, these actions might include misconfiguring security groups, VPC configurations or credential settings, disabling encryption keys or making the encryption keys inaccessible, attempting to connect from an IP address that has not been confirmed and processed in the whitelist of approved IP addresses, attempting to connect when the number of connections is already at the connection limit, client-side DNS issues, etc.);
4. Due to factors outside Redis’ reasonable control (e.g., natural disasters, war, acts of terrorism, riots, government action, or a network or device failure at Customer’s site or between Customer’s site and the Cloud Services);
5. That result from the use of services, hardware, or software provided by a third party, including issues resulting from inadequate bandwidth or related to third-party software or services, such as cloud platform services on which the Cloud Services run;
6. Caused by Customer’s use of the Cloud Services after Redis advises Customer to modify Customer’s use of the Cloud Services, if Customer did not modify their use as advised;
7. Caused by Customer exceeding the Provisioned Workload of its existing Cloud Services plan that results in a slowdown of the Cloud Services after Redis has notified Customer that additional resources are required to meet the Actual Workload;
8. After Grace Period has ended without resolution of a shortfall in the Provisioned Workload due to Customer’s lack of cooperation;
9. During or with respect to preview, pre-release, beta, or trial versions of the Cloud Service, a faulty version of the Cloud Service that is still pending Customer’s approval in order to be upgraded to a better version, feature, or software (as determined by us);
10. That result from Customer’s unauthorized action or lack of action when required, or from Customer’s employees, agents, contractors, or vendors, or anyone gaining access to Redis’ network by means of Customer’s passwords or equipment, or otherwise resulting from Customer’s failure to follow appropriate security practices;
11. That result from Customer’s failure to adhere to any required configurations, use supported platforms, follow any policies for acceptable use, or Customer’s use of the Service in a manner inconsistent with the features and functionality of the Service (for example, attempts to perform operations that are not supported) or inconsistent with Redis published guidance;
12. That result from faulty input, instructions, or arguments (for example, a request to run a Lua script that runs in an infinite loop); or
13. That result from Customer’s attempts to perform operations that exceed prescribed quotas or that resulted from Redis’ throttling of suspected abusive behavior; or arising from Redis’ suspension and termination of Customer’s right to use Redis Enterprise Cloud in accordance with the Agreement.

If availability is impacted by factors other than those explicitly used in the Monthly Uptime Percentage calculation, then Redis may in its 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. 

5. Maintenance.

5.1 Maintenance Windows. 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 pro 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 essentials 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, Maintenance may complete outside the Maintenance Window.

5.2 Maintenance Notice. 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 pro plans only. Redis will not provide Maintenance notice to Customers on essentials plans. Notwithstanding plan type or any Maintenance Windows selected, Redis reserves the right to perform urgent Maintenance activities as soon as they are needed.

6. Customer Cooperation. 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.