Redis CLI - The Only Tool That Works at 3AM

Redis CLI is a terminal program that connects to your Redis server. That's it. No fancy shit, no wizards. When Redis 7.0.5 decides to lock up during Black Friday and your fancy monitoring dashboard is showing green while customers are screaming, you SSH into that server and type redis-cli like some kind of Unix wizard from 1987.

Basic Connection - When It Actually Works

## This works if you're lucky
redis-cli

## This probably won't work on your first try
redis-cli -h redis.prod.company.com -p 6379
## Error: Could not connect to Redis at redis.prod.company.com:6379: Connection refused
## (Because of course the firewall is blocking it)

## Don't do this - your password ends up in bash history
redis-cli -h redis.example.com -p 6379 -a supersecretpassword

## Do this instead - set the auth as an environment variable
export REDISCLI_AUTH=\"supersecretpassword\"
redis-cli -h redis.example.com -p 6379

Last month I spent 4 fucking hours debugging "connection refused" because Redis was bound to 127.0.0.1 instead of 0.0.0.0. Four hours of my life I'll never get back. Check your bind directive in redis.conf - it defaults to localhost only and will ruin your day. Docker makes this worse because Redis 6.2+ inside a container won't talk to the outside world unless you actually expose port 6379 properly, which nobody remembers to do until prod breaks.

WSL2 warning: If you're on Windows with WSL2, Redis networking is completely fucked. localhost sometimes works, sometimes doesn't. Try 127.0.0.1 explicitly or use $(hostname).local - I've wasted entire afternoons on this garbage.

The Redis 6+ ACL gotcha: Getting NOAUTH Authentication required even with the right password? Redis 6.0+ changed auth to require usernames. Try AUTH myuser mypassword instead of just AUTH mypassword. This broke our deployment pipeline in production and took 3 hours to figure out because the error message is complete garbage.

Two Ways to Use Redis CLI

Interactive mode - you stay connected and type commands:

redis-cli
127.0.0.1:6379> SET user:1000 \"John Doe\"
OK
127.0.0.1:6379> GET user:1000
\"John Doe\"
127.0.0.1:6379> KEYS user:*
1) \"user:1000\"
## Don't run KEYS in production - it'll lock up your database

One-shot mode - run a single command and exit:

## Good for scripts
redis-cli SET counter 1
redis-cli INCR counter

## This actually works in bash scripts
USER_COUNT=$(redis-cli GET user:count)
if [ \"$USER_COUNT\" -gt 1000 ]; then
    echo \"Too many users!\"
fi

Interactive mode has tab completion which is nice, but it'll freeze your terminal if Redis is slow. One-shot mode is better for scripts because you get proper exit codes when things fail.

Actually Useful Redis Commands

Strings (the basic stuff):

SET user:session:abc123 \"logged_in\"
GET user:session:abc123
EXPIRE user:session:abc123 3600  # Will expire in 1 hour
TTL user:session:abc123          # Check time left (returns -1 if no expiry)

## This actually works for counters
INCR page:views:today
## Returns the new count

Hashes (when you need object-like data):

HSET user:1000 name \"Alice\" email \"alice@example.com\"
HGETALL user:1000  # Gets everything - can be slow on big hashes
HGET user:1000 name  # Just get one field

## Careful with HINCRBY - it'll create the field if it doesn't exist
HINCRBY user:1000 login_count 1

Lists (for queues that will bite you):

LPUSH queue:tasks \"process_payment\" \"send_email\"
RPOP queue:tasks  # Get from the other end (queue behavior)

## LRANGE can crash your server if the list is huge
LRANGE queue:tasks 0 10  # Only get first 10 items
LLEN queue:tasks  # At least this is O(1)

The key thing about Redis data structures: they're fast until they're not. HGETALL on a hash with 100k fields will lock up Redis for seconds. LRANGE on a million-item list will make your users very unhappy.

When Redis Is Acting Weird - Debugging Commands

MONITOR - See every command hitting Redis in real-time:

redis-cli MONITOR
## Warning: This will flood your terminal and slow down Redis
## I once left this running during a traffic spike and made everything worse

Latency checking - Find out if Redis itself is slow:

redis-cli --latency -h redis.example.com
## If you see numbers above 10ms consistently, something's wrong

redis-cli --latency-history -h redis.example.com -i 1
## This shows latency over time - useful for spotting patterns

Memory debugging - Figure out what's eating all your RAM:

redis-cli INFO memory
## Look for used_memory_human and maxmemory_human

redis-cli --bigkeys
## This will scan EVERY key and find the biggest ones
## Don't run this on production during peak hours - it'll block Redis
## Seriously, it once took down our prod Redis for 5 minutes

## If you suspect a specific key is huge:
redis-cli MEMORY USAGE user:suspicious_key

Fair warning about --bigkeys: I ran this on our main Redis cluster (12M keys, Redis 6.2.1) and it took 47 minutes. Forty-seven fucking minutes. Our monitoring alerts went nuts because latency spiked to 800ms. Run this shit on a replica or during maintenance, never on the master during business hours.

For actual monitoring, use Grafana with the Redis datasource plugin. It doesn't block operations like CLI commands do.

Scripting Redis CLI (For When You Need to Automate This Mess)

Simple health check that actually works:

#!/bin/bash
## Check if Redis is alive and responding
if redis-cli ping | grep -q PONG; then
    echo \"Redis is up\"
    exit 0
else
    echo \"Redis is down\"
    exit 1
fi

Export data without crashing everything:

## Export specific keys (be careful with large datasets)
redis-cli --scan --pattern \"user:*\" | head -1000 | xargs redis-cli MGET > users.txt

## Bulk operations using pipe mode
echo -e \"SET key1 value1
SET key2 value2
SET key3 value3\" | redis-cli --pipe

Pipeline mode can be stupidly fast - I've seen it process 50k operations per second. But if Redis is under heavy load, it might just make things worse by flooding it with commands. Use with caution.

Cluster Commands (If You Hate Yourself)

Redis Cluster - because single-node Redis isn't complicated enough:

## Connect to cluster - note the -c flag
redis-cli -c -h cluster-node1.example.com -p 7000

## See which nodes are actually alive
redis-cli -h cluster-node1.example.com -p 7000 CLUSTER NODES

## Check if your cluster is completely broken
redis-cli -h cluster-node1.example.com -p 7000 CLUSTER INFO

Redis Sentinel - automatic failover that sometimes works:

## Connect to Sentinel (different port usually)
redis-cli -h sentinel1.example.com -p 26379

## Find out which node is the master right now
redis-cli -h sentinel1.example.com -p 26379 SENTINEL masters

Cluster mode will redirect your commands to different nodes automatically, which is nice when it works. When it doesn't work, you'll get MOVED errors and have to figure out which node actually has your data. Fun times.

Useful Command-Line Flags

Output formatting for when you need parseable data:

## Raw output (no quotes) - good for scripts
redis-cli --raw GET user:1000

## CSV format - useful for exports
redis-cli --csv HGETALL user:1000

Batch operations:

## Run commands from a file
redis-cli < commands.txt

## Repeat a command (useful for testing)
redis-cli -r 10 INCR counter

## Ping every second for 5 times
redis-cli -r 5 -i 1 PING

That's the Redis CLI survival guide. Learn these commands, avoid the stupid gotchas, and don't run KEYS * in production unless you want to explain to your CEO why the website is down. When you inevitably break something anyway, Stack Overflow has the answers the official docs don't.

You think you know Redis CLI? Wait until you try the advanced features. They work perfectly in your local dev environment, then spectacularly fuck up your production cluster in ways that make senior engineers cry.

Pipeline Mode - Fast Until It Isn't

Pipeline mode sends a bunch of commands at once instead of waiting for each response. It's faster in theory, but has some nasty gotchas:

## Create a file with commands
cat > bulk_operations.txt << 'EOF'
SET user:1001 "Alice Johnson"
SET user:1002 "Bob Smith"
SET user:1003 "Carol Davis"
EOF

## Pipe them all at once
redis-cli --pipe < bulk_operations.txt

Reality check: Pipeline mode can hit 40k ops/sec on decent hardware (tested on Redis 7.0.4, m5.large instance). But send 50k pipeline commands to a Redis instance already doing 20k ops/sec and watch everything burn. The entire cluster will slow to a crawl because you flooded the event loop.

The gotcha: Pipeline doesn't tell you which specific command failed. You get back a list of responses like OK OK ERR WRONGTYPE OK and have to figure out which command position 3 was. Fun when you're debugging 10,000 operations.

## Generate a million SET commands (this will probably crash something)
seq 1 1000000 | awk '{print "SET key:"$1" value:"$1}' | redis-cli --pipe
## Don't actually run this unless you want to explain to your team why Redis is down

I once pipeline-loaded 500k keys during lunch (Redis 6.2.5, 8GB instance) and hit the maxmemory limit. Redis started evicting active user sessions to make room. Customer support got 847 "logged out randomly" tickets in 20 minutes. Learn from my fuckup.

Lua Scripting - When Redis Commands Aren't Enough

Sometimes you need to do multiple operations atomically, and that's where Lua scripts come in. Fair warning: Lua syntax is weird if you're used to normal programming languages.

## Simple rate limiting script
redis-cli EVAL "
  local key = KEYS[1]
  local limit = tonumber(ARGV[1])

  local current = redis.call('GET', key)
  if current == false then
    redis.call('SETEX', key, 60, 1)
    return 1
  elseif tonumber(current) < limit then
    return redis.call('INCR', key)
  else
    return 0
  end
" 1 "rate_limit:user:123" 10

What this does: Checks if a user has hit their rate limit (10 requests per minute). Returns the current count or 0 if they're over the limit.

The annoying part: Lua scripts block Redis completely. I wrote a script that scanned through hash keys to clean up expired entries - seemed harmless. It ran for 43 seconds on our prod Redis 6.0.9 instance with 8M keys. Forty-three seconds of complete lockup during Black Friday. The website literally stopped working and I wanted to crawl into a hole.

Pro tip: You can load scripts once and reuse them with SCRIPT LOAD and EVALSHA, but honestly, for simple stuff, just use EVAL and keep the scripts short.

Production Monitoring Scripts That Actually Work

Simple health check (what you'll actually use):

#!/bin/bash
## Check if Redis is alive
if redis-cli ping | grep -q PONG; then
    echo "Redis is up"
else
    echo "Redis is down"
    exit 1
fi

## Check memory usage (optional)
MEMORY_PERCENT=$(redis-cli info memory | grep used_memory_pct | cut -d: -f2 | tr -d '\r')
if [ "${MEMORY_PERCENT%.*}" -gt 90 ]; then
    echo "WARNING: Redis using ${MEMORY_PERCENT}% memory"
fi

Grab key metrics for monitoring:

## Get the important stuff
redis-cli info stats | grep -E "(total_commands_processed|keyspace_hits|keyspace_misses)"
redis-cli info memory | grep -E "(used_memory_human|used_memory_pct)"
redis-cli info clients | grep connected_clients

That's it. Don't overcomplicate monitoring scripts - they need to work when everything else is broken. Your fancy monitoring dashboard will be down too, guaranteed.

For real monitoring, use Grafana with the Redis exporter. But when that's broken too, these CLI scripts will save your ass.

Other Stuff You Might Need

Data migration between Redis instances:

## Simple key copy (for small datasets)
redis-cli -h old-redis.com --scan --pattern "user:*" | \
  xargs -I {} sh -c 'VAL=$(redis-cli -h old-redis.com get "{}"); redis-cli -h new-redis.com set "{}" "$VAL"'

Basic cleanup of expired keys:

## Find keys without expiration
redis-cli --scan --pattern "session:*" | while read key; do
  TTL=$(redis-cli TTL "$key")
  if [ "$TTL" = "-1" ]; then
    echo "Key $key has no expiration"
  fi
done

Security basics:

## Set up a read-only user (Redis 6+)
redis-cli ACL SETUSER readonly on >password123 +@read ~*

## Check what permissions you have
redis-cli ACL WHOAMI

That's the advanced stuff. It works great in your local Docker container, then breaks production in fascinating ways. Test this shit on replicas first or you'll be updating your LinkedIn.

Redis CLI is for fixing broken things fast. When Redis shits itself at 3AM, you don't have time to read documentation. You need commands that work.