Your Redis Cache Has an SLA: What ElastiCache, Azure Cache for Redis and Memorystore Pay When They Fail

October 1, 2026

The cache tier in front of your database has an SLA, and most teams never file a claim against it. ElastiCache, Azure Cache for Redis and Memorystore all commit to uptime between 99.5% and 99.999%, and all three pay credits when they miss. The catch: a single-AZ Redis cluster needs almost four hours of downtime before it owes you anything, and the Basic tier of Azure Cache for Redis has no SLA at all. Here is the exact tier map and what a real outage pays.

Why cache claims get skipped

Caches sit in a blind spot. When Redis goes down your app usually survives, just slower and with a heavier database, so nobody treats it as an outage. The provider still counts every minute against its monthly uptime number, and an unfiled claim vanishes.

There is a second reason claims fail, in the fine print. Every provider here defines downtime as total failure: a minute counts only when every connection attempt to the primary endpoint fails. One successful request and the minute is not downtime. Latency spikes, evictions and slow failovers never earn a credit.

The deadlines are short. Google gives 30 days from eligibility, Microsoft wants the claim within 60 days of the incident, AWS by the end of the second billing cycle.

AWS ElastiCache: five separate SLAs

AWS split ElastiCache into five commitments in its October 2024 SLA. Which one applies depends on how the cluster is deployed:

For Redis and Valkey, "Multi-AZ" means automatic failover enabled, a primary and replica in each shard across at least two availability zones, and Redis OSS 6.2 or newer created after January 13, 2023 (or with a service update applied since). Everything else is Single-AZ under the 99.5% promise: 4.4 minutes of downtime allowed per month versus 3 hours 39 minutes.

Unavailability for node-based clusters means all connection requests to the shard primary fail during a 1-minute interval. Serverless caches instead count failed requests: a "-CLUSTERDOWN" or "-ERR internal error" response for Valkey or Redis OSS, a "SERVER_ERROR server temporarily unavailable" for Memcached. Minutes with no requests count as fully available.

Credits are a percentage of the affected configuration's charges in that region for the billing cycle, floored at $1 and applied to future bills. Claims under the five SLAs cannot be stacked for the same deployment. File a support case with "ElastiCache SLA Credit Request" in the subject, the dates and times, cache, cluster or shard names, the region, and request logs documenting the errors, by the end of the second billing cycle after the incident.

Azure Cache for Redis: the Basic tier has no SLA at all

Microsoft's October 2026 consolidated SLA makes the tiers explicit, and the first row surprises most people: the Basic tier of Azure Cache for Redis is not covered by any SLA. You pay for Basic, you get a Redis server and zero uptime commitment.

The newer Azure Managed Redis product follows the same shape: high availability earns 99.9%, distributing primary and replica shards across two or more zones raises it to 99.99%. Note the ceiling: cache credits cap at 25%, with no 100% tier. Even a week-long outage refunds at most a quarter of that cache's bill.

Downtime is measured per cache: a minute is unavailable when there is no connectivity throughout the minute between one or more cache endpoints and Microsoft's internet gateway. Claims go through the Azure portal as a billing support request with the incident ID, subscription ID and impact evidence, within 60 days of the incident. Credits apply only to the affected tier's fees.

GCP Memorystore: a 50% cap and a 30-day window

Google's Memorystore SLA (last modified March 4, 2025) covers six configurations, measured per instance per region on a calendar month. All rows share the same ladder: 10% below the commitment, 25% below 99.0%, 50% below 95.0%, capped at 50% of the covered service's monthly bill.

Two exceptions: in Mexico and Stockholm the multi-zone cluster commitment drops to 99.95%. Downtime follows the total-failure rule: all requests to a shard primary must fail (cluster), all requests to a Standard tier instance must fail, or for Memcached all requests on all nodes must fail. Partial minutes do not count. One asymmetry worth knowing: scheduled maintenance is excluded for Standard tier and Memcached, but not for Redis Cluster and Valkey, so a Google-initiated maintenance window that kills a HA cluster still counts.

Notify Google technical support within 30 days of eligibility; the credit lands within 60 days of the request.

DigitalOcean: Redis lives inside Managed Databases

DigitalOcean sells no standalone cache. Its Redis and Valkey run under the Managed Databases SLA (June 3, 2025): 99.95% with standby nodes, 99.5% without. Unavailability means no external connectivity for more than five consecutive minutes. A 30-minute blip on a single node sits at 99.93%, clears the 99.5% bar and pays nothing; the same blip on a standby cluster breaches 99.95% and earns 10%. Claims go to support by the end of the second billing cycle.

The money math on a $300 cache bill

Say you spend $300 a month across a multi-AZ ElastiCache cluster, an Azure Enterprise cache in three zones and a multi-zone Memorystore cluster, all carrying 99.99% commitments. A 43,800-minute month against a single outage:

The same two-hour outage on a single-AZ ElastiCache cluster or a DigitalOcean single-node database pays zero: 99.73% clears the 99.5% bar, which needs roughly 3 hours 39 minutes to breach. A 30-minute outage on an Azure Standard or Memorystore Standard instance also pays zero, since 99.93% still clears 99.9%. The tier you deploy decides what a claim is worth, and it is the factor most teams never check.

Cache credits come only from total failure: a minute with even one successful connection is not downtime on any of the four providers. Check your deployment tier before you count on a credit, because a single-AZ or Basic-tier cache can burn hours of outage without owing you a dollar.

What to do now

Pick your two most expensive cache deployments, open their configuration, and note the tier, the zone layout, and the commitment it maps to in the tables above. Put those numbers in your runbook next to the cluster names. When the next "Redis was slow" alert fires, the question is whether the cluster breached its tier, and that answer decides whether an hour of claim paperwork is worth doing.

The credits are contractual. They just need someone to file, inside the window, with the request logs attached.