Troubleshooting High Network Usage in Redis Cloud

When Redis Cloud experiences sustained high network usage, the root cause is typically excessive payload size, inefficient command patterns, connection instability, or plan-level throughput limits. This article provides step-by-step diagnostics, stabilization guidance, and long-term fixes. For alert interpretation and upgrade guidance, see High Network Usage Warning in Redis Cloud: What It Means and What to Do Next.

Quick Diagnostic Checklist

Confirm:

• Monthly bandwidth usage (Essentials)

• Throughput vs plan or configured limit

• Latency percentiles

• Shard or node CPU

• Connection counts

In the console:

Databases → Choose the specific Database → Configuration tab for more information; Metrics tab for deeper Metrics

Optional CLI:

SLOWLOG GET 200

Identify Heavy Commands

Look for:

• FT.SEARCH on large datasets

• Large ZRANGE or LRANGE operations

• KEYS usage

• Large JSON.GET operations

• Lua scripts processing large keysets

If heavy commands dominate the slowlog, refactor or isolate them.

Inspect Payload Size

High average request size reduces achievable ops/sec.

Indicators:

• Multi-KB JSON documents

• Large blob storage patterns

• Full object reads when only partial fields are required

Mitigation:

• Store structured data in hashes or RedisJSON and read only required paths

• Compress large values where appropriate

• Break large objects into smaller logical keys

Check Connection Behavior

Symptoms of connection stress:

• Rapid spikes in connection count

• Frequent reconnect attempts

• Elevated proxy or shard CPU

Ensure:

• Clients use connection pooling

• Retry logic includes exponential backoff

• Timeouts are configured correctly

• Applications do not open per-request connections

On Essentials, respect per-database connection limits.
On Pro, very high connection counts can still degrade performance even without a fixed cap.

Distinguish Bandwidth vs Throughput Saturation

Bandwidth-bound:

• Monthly usage near plan cap

• Heavy egress traffic

• Throttling tied to subscription limits

Throughput-bound:

• Ops/sec flat-lining at ceiling

• Latency rising with traffic

• CPU approaching sustained high utilization

Correct classification determines whether optimization or plan changes are required.

Stabilization Steps During an Incident

If performance degradation is ongoing:

• Pause bulk jobs and non-critical scans

• Reduce traffic spikes if possible

• Enforce retry backoff to prevent amplification

• Isolate heavy database into separate subscription if needed

If repeatedly exceeding Essentials limits, begin migration planning to Pro.

Scaling and Long-Term Fixes

Optimize Traffic Patterns

• Replace full scans with incremental patterns

• Batch small commands using pipelining

• Remove unnecessary heavy commands from hot paths

Adjust Throughput (Pro)

Increase configured ops/sec under:

Database → Performance → Throughput

Re-benchmark and monitor latency.

Upgrade Plan

Move from Essentials to Pro when:

• Bandwidth limits repeatedly trigger throttling and upgrading within Essentials tiers is no longer sufficient

• Throughput ceilings limit growth

• Workload isolation is required

• Advanced networking or monitoring is needed

Monitoring Best Practices

Track:

• Total throughput

• Latency percentiles

• Bandwidth trends

• Connection count

• CPU utilization

Alert at:

• 75 to 80 percent sustained utilization

• Latency growth correlated with throughput ceiling

• Unexpected connection spikes

Summary

High network usage in Redis Cloud is typically caused by:

• Large payloads

• Inefficient commands

• Connection instability

• Plan-level throughput limits

• Sustained legitimate growth

Durable resolution requires workload optimization, correct throughput sizing, and selecting the appropriate plan tier for expected traffic patterns.