Stay organized with collections
Save and categorize content based on your preferences.
The Memorystore for Valkey Service Level Agreement (SLA) excludes outages "caused by factors outside of Google's reasonable control". This page describes some of the user-controlled configurations and workloads that can cause an outage for a Memorystore for Valkey instance to be excluded.
Introduction
Memorystore strives to give you as much control over how your instance is configured and used as possible. This includes some configurations or workload patterns that increase the risk of instance downtime. If your instance becomes unhealthy and Memorystore determines that it was out of compliance with the operational limits and best practices as described on this page, then the downtime period is not covered by (or does not count against) the Memorystore SLA.
This list of operational limits and best practices is presented to inform you which configurations and workload patterns present these risks, ways to avoid them, and ways to mitigate the risks when the configuration is required for your business environment.
Excluded configurations
This section lists configurations that can cause your instance to be excluded from the Memorystore SLA.
General configuration requirements
If the instance is configured without high availability (0 replicas), then the SLA does not apply. Only Memorystore for Valkey instances configured for high availability are covered by the Memorystore SLA.
Resource constraints
The following resource constraints must be avoided to retain SLA coverage:
CPU overloaded: If your CPU utilization is consistently high, your instance is not properly sized for your workload or you are using Valkey commands improperly. If CPU resources are overloaded, you may not be covered by the SLA.
Memory overloaded: If your memory usage is consistently high, your instance is not properly sized for your workload, and may not be covered by the SLA.
shared-core-nano node type
The Memorystore SLA doesn't apply to instances that use the shared-core-nanonode type. The node type isn't suitable for most production workloads because it has insufficient performance and is too small for most production use cases.
Best practices
Best practices are guidelines
that you can use to receive the best possible experience with Memorystore for Valkey.
The SLA might not cover downtime events that result from you
not following these best practices.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Operational guidelines\n\nThe Memorystore for Valkey [Service Level Agreement (SLA)](/memorystore/sla) excludes outages \"caused by factors outside of Google's reasonable control\". This page describes some of the user-controlled configurations and workloads that can cause an outage for a Memorystore for Valkey instance to be excluded.\n\nIntroduction\n------------\n\nMemorystore strives to give you as much control over how your instance is configured and used as possible. This includes some configurations or workload patterns that increase the risk of instance downtime. If your instance becomes unhealthy and Memorystore determines that it was out of compliance with the operational limits and best practices as described on this page, then the downtime period is not covered by (or does not count against) the Memorystore [SLA](/memorystore/sla).\n\nThis list of operational limits and best practices is presented to inform you which configurations and workload patterns present these risks, ways to avoid them, and ways to mitigate the risks when the configuration is required for your business environment.\n\nExcluded configurations\n-----------------------\n\nThis section lists configurations that can cause your instance to be excluded from the Memorystore SLA.\n\n### General configuration requirements\n\nIf the instance is configured without [high availability](/memorystore/docs/valkey/ha-and-replicas) (0 replicas), then the SLA does not apply. Only Memorystore for Valkey instances configured for high availability are covered by the Memorystore SLA.\n\n### Resource constraints\n\nThe following resource constraints must be avoided to retain SLA coverage:\n\n- **CPU overloaded:** If your CPU utilization is consistently high, your instance is not properly sized for your workload or you are using Valkey commands improperly. If CPU resources are overloaded, you may not be covered by the [SLA](/memorystore/sla).\n\n- **Memory overloaded:** If your memory usage is consistently high, your instance is not properly sized for your workload, and may not be covered by the [SLA](/memorystore/sla).\n\n### `shared-core-nano` node type\n\nThe Memorystore SLA doesn't apply to instances that use the `shared-core-nano` [node type](/memorystore/docs/valkey/instance-node-specification). The node type isn't suitable for most production workloads because it has insufficient performance and is too small for most production use cases.\n\nBest practices\n--------------\n\n[Best practices](/memorystore/docs/valkey/general-best-practices) are guidelines\nthat you can use to receive the best possible experience with Memorystore for Valkey.\nThe [SLA](/memorystore/sla) might not cover downtime events that result from you\nnot following these best practices."]]
