Redis Cloud Shows Healthy but My Application Fails: Connectivity and Latency Triage

Redis Cloud manages the infrastructure that serves your database, but an application can still report connection failures, write errors, or high latency while the database appears Active in the Redis Cloud Console. Application access also depends on the database endpoint, network path, DNS, TLS, authentication, client configuration, connection behavior, workload, and available database resources.

Use this guide when Redis Cloud appears healthy but your application reports errors such as ECONNREFUSED, connection timeouts, sudden connection drops, HTTP 500s caused by Redis errors, OOM or maxmemory errors, increased latency, or Communication with resource interrupted. Please try later. 

Start with the Quick Fix table, then use the Step-by-Step Triage to determine whether the issue belongs to the client, network, workload, database, or Redis Cloud service path.

An Active database status does not confirm that every part of the application data path is healthy. Correlate the Redis Cloud status with application errors, Redis Cloud metrics, and a direct connection test from the same network as the affected application.

Quick Fix

Prerequisites

Before troubleshooting, collect:

• Redis Cloud subscription ID

• Database ID and name

• Cloud provider and region

• Database endpoint and port from the Redis Cloud Console

• Whether the application uses a public or private endpoint

• Private connectivity method, if applicable (VPC peering, AWS PrivateLink, Google Cloud Private Service Connect, or Transit Gateway)

• Whether a customer-managed proxy or load balancer sits between the application and Redis Cloud

• TLS enabled

• Redis client library and version

• Exact application error and timestamp, including time zone

• Scope of impact: one client, one application, one region, one database, or all clients

• Recent changes to application, networking, database, credentials, scaling, migration, or maintenance

For the affected time range, capture Redis Cloud metrics for:

• Connections

• Latency

• Read latency

• Write latency

• Ops/sec

• Network ingress and egress

• Used memory

• Evictions

For the full list and definitions of Redis Cloud metrics, see Monitor database performance.

Redis Cloud customers do not have access to the underlying Redis Cloud nodes. Do not use Redis Software procedures that require rladmin, supervisorctl, node shell access, port 9443 administrative APIs, or node-level firewall changes when troubleshooting a Redis Cloud database.

Step-by-Step Triage

1. Determine the Scope of the Failure

First determine how broadly the issue is affecting applications.

If production data is inaccessible, do not wait to finish every troubleshooting step before contacting Redis Support.

2. Verify the Database Endpoint and Connection Configuration

Copy the current endpoint from the Redis Cloud Console instead of relying on an old application configuration or resolved IP address.

Redis Cloud provides connection information for the database in the console. For the supported workflow to retrieve the endpoint, username, password, and connection examples, see Connecting to your Redis Cloud database and Connect to a Redis Cloud database.

Confirm:

• Hostname: Matches the current Redis Cloud database endpoint.

• Port: Matches the port shown in the Redis Cloud Console.

• Endpoint type: The application is using the correct public or private endpoint.

• TLS: The client uses the required TLS configuration.

• Authentication: The client uses the database's configured authentication mode: passwordless access, the default-user password, or an ACL username and password.

• Active-Active: The application connects to the intended regional endpoint.

• Clustered databases: If the OSS Cluster API is enabled for the database, the client is cluster-aware and correctly configured for that topology.

Do not hardcode the IP address returned by DNS for a Redis Cloud endpoint.

3. Test From the Same Network as the Application

Test connectivity from a host, pod, container, VM, or bastion that uses the same network path as the affected application.

For a non-TLS connection:

Select the command that matches the database's TLS and authentication configuration.

For a non-TLS, passwordless connection:

redis-cli -h <endpoint> -p <port> PING

For a non-TLS connection using the default-user password:

redis-cli -h <endpoint> -p <port> --askpass PING

For a non-TLS connection using an ACL user:

redis-cli -h <endpoint> -p <port> --user <username> --askpass PING

For a TLS, passwordless connection:

redis-cli -h <endpoint> -p <port> --tls PING

For TLS using the default-user password:

redis-cli -h <endpoint> -p <port> --tls --askpass PING

For TLS using an ACL user:

redis-cli -h <endpoint> -p <port> --tls --user <username> --askpass PING

If the client requires a specific CA bundle, add the following option to the applicable TLS command:

--cacert <redis-ca.pem>

Do not supply --askpass or --user to a passwordless database. Supplying authentication when the database is configured for passwordless access can cause the connection attempt to fail.

Interpret the result:

Do not use curl to validate a Redis database connection. Redis uses the Redis protocol rather than HTTP. Use redis-cli, Redis Insight, or the same Redis client library used by the application.

4. Check the Network Path

If the direct Redis test fails, determine which network path the application uses.

Public Endpoint

Check:

• The application uses the public endpoint shown in the Redis Cloud Console.

• The application's actual outbound IP or CIDR is permitted when a CIDR allow list is configured.

• The hostname resolves from the application environment.

• Outbound TCP traffic to the database port is allowed.

• NAT gateways, egress gateways, proxies, or hosted platforms are not changing the source address unexpectedly.

If necessary, confirm the application's actual outbound address with the network or hosting provider rather than assuming the source address is the address assigned directly to the application host.

Private Endpoint

Redis Cloud Pro supports private connectivity methods depending on the cloud provider, including VPC peering, AWS PrivateLink, Google Cloud Private Service Connect, and AWS Transit Gateway.

Check:

• The configured private connectivity method is active.

• The application is using the private endpoint.

• DNS resolves as expected from the application network.

• Customer-side routes are still present.

• Security groups, NACLs, firewalls, and Kubernetes NetworkPolicies permit the traffic.

• CIDR allow lists include the required addresses when applicable.

For the current supported private connectivity configuration, use the Redis product documentation rather than recreating the setup in this article:

• VPC peering

• AWS PrivateLink

• AWS Transit Gateway

• Google Cloud Private Service Connect

A successful DNS lookup does not prove that the private data path is reachable. A changed route, security rule, NACL, or private-connectivity configuration can still cause TCP connections to time out while Redis Cloud itself remains available.

Customer-Managed Proxy or Load Balancer

If the application connects through a TCP proxy or load balancer, isolate the two sides of the path:

1. Application → proxy

2. Proxy → Redis Cloud

Verify:

• The proxy listener is reachable.

• The proxy can resolve the Redis Cloud hostname.

• The proxy can reach the Redis Cloud database port.

• TLS passthrough or termination behavior matches the application design.

• Proxy connection, file descriptor, CPU, memory, and timeout limits are not exhausted.

Do not route Redis traffic through an HTTP reverse-proxy configuration.

5. Check for Connection Churn or Reconnect Storms

Open Redis Cloud Metrics and review the Connections graph around the failure.

Look for:

• Connections suddenly dropping to zero.

• A large reconnect spike immediately afterward.

• Connections approaching the applicable database or plan limit.

• Application autoscaling or deployment activity at the same time.

• Large numbers of short-lived connections.

• Connection pools that grow with each application instance.

A brief network event, maintenance operation, or deployment can become a larger outage when every client reconnects simultaneously.

If the connection graph shows this pattern, continue with Managing Connection Surges and Reconnect Storms.

6. Check Authentication and TLS

Authentication and TLS problems can appear as generic connectivity failures at the application layer.

Check whether:

• A Redis password or ACL credential was recently changed.

• The application still contains an old Kubernetes Secret, environment variable, Vault secret, or configuration value.

• The application uses the correct Redis username.

• TLS requirements changed.

• The application trusts the appropriate CA certificate when certificate validation is configured.

• The application is connecting to the intended database rather than an endpoint copied from another environment.

For detailed authentication troubleshooting, use Troubleshooting Redis Cloud Authentication Errors (WRONGPASS, AUTH failed).

7. Check Memory When Reads Work but Writes Fail

If applications can read existing data but writes return OOM, maxmemory, or related errors, check the database's memory state and eviction policy.

With a noeviction policy, writes that require additional memory can fail when the effective memory limit is reached rather than evicting existing keys.

Do not use the visible dataset size alone to rule out memory pressure. Support cases can involve additional pressure from:

• Replication

• Persistence-related activity

• Imports or migrations

• Bulk write activity

• Memory fragmentation

• Uneven shard distribution

A multi-shard database can also experience pressure on one shard before a database-level view makes the imbalance obvious.

If memory pressure is indicated, use the existing Redis KB guidance instead of continuing the generic connectivity workflow:

• Troubleshooting High Memory Usage in Redis Cloud

• High Memory Usage Warning in Redis Cloud: What It Means and What to Do Next

If production writes are blocked, contact Redis Support while investigating the memory condition.

8. Check Redis and Application Latency Separately

Application latency and Redis latency are not necessarily the same.

In Redis Cloud Metrics, compare the same incident window for:

• Latency

• Read latency

• Write latency

• Ops/sec

• Connections

• Network ingress

• Network egress

• Used memory

• Evictions

Redis Latency Increases With Throughput

If Redis latency rises as Ops/sec or workload volume increases, continue with Handling Traffic Spikes and Throughput Above Configured Ops/Sec.

Redis Latency Increases With Network Traffic or Large Responses

Review Slowlog and workload patterns for:

• Large values

• Large collection responses

• KEYS

• Large HGETALL, LRANGE, ZRANGE, JSON.GET, or FT.SEARCH operations

• Lua scripts operating on large datasets

• Retry amplification

• Connection churn

For detailed payload, command, and network troubleshooting, use Troubleshooting High Network Usage in Redis Cloud.

Redis Latency Is Normal but the Application Is Slow

Investigate the parts of the path outside Redis, including:

• Application CPU or memory pressure

• Thread-pool or event-loop saturation

• Connection-pool exhaustion

• Network round-trip time

• Cross-region connectivity

• DNS resolution

• TLS negotiation

• Customer-managed proxy or load-balancer latency

• Client timeout and retry behavior

9. Check Maintenance, Failover, Scaling, and Client Recovery

Redis Cloud maintenance and failover can cause short-lived application disconnects. Redis product documentation notes that clients should reconnect using the database hostname and refresh DNS when necessary.

If an incident occurred during or shortly after maintenance, a database resize, an upgrade, a migration, or another infrastructure change, check:

• Redis Cloud maintenance notifications.

• Whether the application reconnects automatically.

• DNS caching behavior.

• Retry and backoff behavior.

• Connection and socket timeouts.

• Whether clients use the Redis Cloud hostname rather than a hardcoded IP.

• Whether your Redis client supports Smart Client Handoffs.

For detailed guidance, see:

• Subscription and database maintenance

• Develop highly available and resilient apps with Redis Cloud

• Smart Client Handoffs: Reduce Disconnects During Upgrades and Maintenance

For planned resiliency testing, use How to Run a Failover Test in Redis Cloud.

Avoid making repeated configuration changes during an active incident. Do not repeatedly resize the database, rotate credentials, change TLS, modify allow lists, or initiate additional database changes unless you have identified that configuration as the likely cause.

10. Handle Communication with resource interrupted. Please try later.

If the Redis Cloud Console displays:

Communication with resource interrupted. Please try later.

record:

• Exact timestamp and time zone.

• Subscription ID and database ID.

• Whether client traffic was also interrupted.

• Whether the database was undergoing maintenance or another update.

• Whether other databases were affected.

If the message occurs once and applications remain healthy, refresh the console and continue monitoring.

If the message persists, the database becomes unavailable, or production traffic is affected, contact Redis Support.

Caution: Do not infer a specific underlying cause, such as a shard crash or restart, from this console message alone. Correlate it with application impact, metrics, maintenance activity, and information provided by Redis Support.

11. Validate Recovery

After the issue is resolved, validate from the same application network that originally failed.

Confirm:

• PING returns PONG.

• Application reads and writes succeed.

• Connection count returns to its expected range.

• Redis latency returns to baseline.

• No new OOM, authentication, TLS, or connection-limit errors appear.

• Application clients recover without repeated manual restarts.

For a temporary read/write validation, you can use:

If your credentials permit writes and it is safe to create a temporary key, choose a unique key name containing a timestamp or UUID. Do not use a fixed key name that could overwrite application data.

Use the applicable connection and authentication options from step 3:

redis-cli <connection-options> SET kb_triage_test:<unique-id> ok NX EX 60
redis-cli <connection-options> GET kb_triage_test:<unique-id>
redis-cli <connection-options> DEL kb_triage_test:<unique-id>

The SET command should return OK, and the GET command should return ok. If SET returns a null result, choose another unique identifier rather than removing or overwriting the existing key.

This is a real write operation. Skip it if the database is read-only, the credentials do not permit SET or DEL, or production change controls prohibit test writes.

When to Contact Redis Support Immediately

Open an urgent Redis Support ticket if:

• Production data is inaccessible.

• All production clients fail to connect.

• Connections drop to zero and do not recover.

• A database that appears Active cannot be reached from any previously working valid client network.

• Reads or writes are unavailable across production clients.

• Communication with resource interrupted. Please try later. persists while client traffic is affected.

• Multiple databases become unavailable at approximately the same time.

• Production writes are blocked by OOM or maxmemory and cannot be stabilized.