Redis CLI, Commands, Troubleshooting, and Cheat Sheet

Anil Jalela · Published Aug 4, 2026 · 33 min read

A Redis command cheat sheet is useful only when it helps an operator choose the right command, understand its cost, preserve evidence, and avoid turning an investigation into an outage. This guide treats redis-cli as a production instrument, not a bag of commands to paste into the busiest node.

The examples use Redis Open Source terminology and current command forms. Test every write against a disposable instance first, confirm the endpoint and role before running it, and adapt ACL permissions to the installed Redis release.

Begin every session with an identity and endpoint check

Many Redis mistakes begin before the first command. A shell history points to an old host, a port-forward targets the wrong environment, or the endpoint now belongs to a promoted primary. Write down the environment, endpoint, expected role, change ticket, and UTC start time. If the purpose is investigation, use an ACL user that cannot write.

redis-cli -h redis.internal -p 6379 --user redis_observer --askpass
redis-cli -u rediss://[email protected]:6379 --askpass

PING
HELLO 3
CLIENT SETNAME incident-4821-observer
INFO server
ROLE

--askpass prevents the password from appearing as a command-line argument. A URI containing a password can leak through shell history, process inspection, logs, or support bundles, so the examples omit it. REDISCLI_AUTH is available for automation, but it is still a secret-bearing environment variable and must be protected by the execution environment. Prefer a secret manager, short-lived job context, restricted service identity, and redacted logs.

Use rediss:// or the applicable TLS options when the server requires TLS. Validate the server name and trust chain. An encrypted connection to an unverified endpoint does not prove that the endpoint is the intended Redis service.

Make redis-cli output fit the job

Do not parse the decorative interactive output when a machine-readable mode is available. Store the Redis and redis-cli versions with collected evidence because reply formats and available options can change across releases.

Ask Redis what a command does

A static cheat sheet cannot replace the command metadata on the installed server. Redis exposes arity, key positions, flags, ACL categories, and documentation. Check that metadata when a command is unfamiliar or when an ACL rule is being reviewed.

COMMAND INFO GET SET SCAN
COMMAND DOCS SET
COMMAND GETKEYS MSET key:1 one key:2 two
ACL CAT
ACL CAT dangerous
ACL DRYRUN redis_observer GET cache:user:42

ACL DRYRUN evaluates whether a user may execute a command without executing it. It is safer than discovering missing privileges during an incident by granting a broad command category. Command categories are convenient starting points, but a production ACL should be reviewed against actual keys and operations.

Redis administrator command map

Use separate ACL users for observation, backup, replication, Sentinel, controlled change, and break-glass administration. The commands below are not a recommendation to grant one user everything. They are an inventory to map to procedures and least-privilege roles.

Important redis.conf options every administrator should review

There is no universal production redis.conf. The correct file depends on whether Redis is a disposable cache, a durable data service, a replica, a Sentinel-managed service, or a Cluster node. Begin with the example file shipped with the exact installed release, then keep a small reviewed configuration in version control. Do not paste a configuration from a different Redis major version and assume unknown or renamed directives will behave safely.

Network, process, and security options

Persistence and recovery options

Memory, latency, and observability options

Valid but unsafe configuration examples

The following directives and values are accepted by current Redis releases, but acceptance does not make them safe. Keep them visible for command coverage, then choose values from the workload, service manager, recovery objective, and measured host limits.

Specialized current options and renamed replacements

Replication, Sentinel, and Cluster settings are topology controls, not generic tuning switches. The next article gives a step-by-step deployment and a dedicated configuration matrix for replicaof, authentication, backlog sizing, write guards, Sentinel timeouts, and Cluster node state.

Change Redis configuration without losing the source of truth

1. Record the Redis version, package, process command line, active configuration path, node role, persistence mode, and current values with narrowly scoped CONFIG GET calls.
2. Read the example redis.conf shipped with that exact release. Check module and managed-service restrictions. Back up the managed file and ACL file with permissions intact.
3. Write the proposed value, capacity calculation, impact, validation signal, and rollback. Test it against production-like data and traffic.
4. When the installed release supports a runtime change, apply one reviewed option with CONFIG SET, observe it, and update configuration management immediately. A runtime success does not make the change restart-safe.
5. Use CONFIG REWRITE only when Redis owns the local configuration lifecycle and the rewrite has been tested with includes. It does not rewrite included files, and directive order can cause a later include to override a rewritten value.
6. For startup-only, security, networking, TLS, threading, storage-path, or topology changes, deploy through configuration management and perform a rolling restart. Start with a replica or disposable node, prove health and catch-up, then proceed.
7. After restart, compare effective values, logs, listeners, ACL behavior, persistence, memory, latency, clients, and role. Run the application smoke test and record the rollback result.

redis-cli --user redis_observer --askpass CONFIG GET maxmemory
redis-cli --user redis_observer --askpass CONFIG GET maxmemory-policy
redis-cli --user redis_observer --askpass CONFIG GET appendonly
redis-cli --user redis_observer --askpass CONFIG GET appendfsync
redis-cli --user redis_observer --askpass INFO persistence
redis-cli --user redis_observer --askpass INFO memory

Avoid CONFIG GET * in tickets or chat. Broad configuration output may expose paths, topology details, renamed commands, module settings, or secret-bearing values on some versions. Collect only the required directives and redact evidence before sharing it.

CONFIG SET changes runtime state. It is not automatically durable across restart. Update configuration management or use a reviewed CONFIG REWRITE where the package model supports it. Record the old value, new value, reason, validation, and rollback before applying any change.

Inspect the key before choosing the command

Redis commands are tied to data types. A key name does not tell you whether its value is a string, hash, stream, list, or module data type. Inspect type, lifetime, encoding, and approximate memory before requesting the whole value.

EXISTS cache:user:42
TYPE cache:user:42
TTL cache:user:42
PTTL cache:user:42
OBJECT ENCODING cache:user:42
MEMORY USAGE cache:user:42 SAMPLES 5

TTL returns -1 when the key exists without expiry and -2 when it does not exist. That distinction matters in cache incidents. MEMORY USAGE is an estimate of the bytes required for the key and value in RAM, including overhead represented by its sampling behavior. It is not the complete memory impact of the application or process.

Iterate with SCAN, not KEYS

KEYS * walks the keyspace in one server operation and can block useful work on a large database. SCAN is incremental. It spreads the work across calls, although a complete iteration still consumes CPU and can affect cache locality. Run it from the appropriate primary, throttle it, and observe latency.

redis-cli --scan --pattern 'cache:user:*' --count 200 -i 0.01
redis-cli --bigkeys -i 0.1
redis-cli --memkeys -i 0.1
redis-cli --keystats --top 20 -i 0.1

A SCAN iteration may return the same element more than once, and elements can appear or disappear while the dataset changes. Do not use it as a transactional snapshot. The COUNT argument is a work hint, not an exact page size. Deduplicate in the client when the action must be idempotent.

--bigkeys, --memkeys, and --keystats scan the database. They are diagnostic jobs, not free queries. Record their start time, throttle them, and stop if latency or CPU crosses the agreed boundary.

Command cheat sheet by data model

Always read the command’s time-complexity variables. O(N) is not automatically dangerous and O(1) is not automatically harmless. The actual N, value bytes, reply size, frequency, and interaction with other clients determine operational impact.

Use SET options to express the write contract

SET can encode useful preconditions directly:

SET lock:invoice:884 worker-17 NX PX 30000
SET cache:user:42 payload XX KEEPTTL
SET session:42 replacement GET EX 900

• NX writes only when the key does not exist.
• XX writes only when the key exists.
• EX and PX apply seconds or milliseconds of expiry.
• GET returns the previous value as part of the operation.
• KEEPTTL retains the existing expiry.

A normal SET replaces the value and discards an existing TTL unless an option preserves or replaces it. This is a common cause of cache keys becoming persistent. For locks, a token and expiry are only part of a correct design. Release must verify ownership atomically, and the application must handle work that outlives the lease.

Use EXEC as the Redis commit, not COMMIT

Redis has no COMMIT command. MULTI begins queueing commands on one connection, EXEC is the commit-like action that runs the queue, and DISCARD abandons the queue before execution. Redis transactions do not provide a relational rollback. A command that fails during execution does not reverse successful commands around it.

WATCH account:42
GET account:42
MULTI
SET account:42 revised-value
EXEC

WATCH provides optimistic concurrency. If a watched key changes before EXEC, the transaction aborts and the client decides whether to retry. Bound retries and add jitter under contention. Lua scripts and Redis Functions can move an atomic decision to the server, but long-running logic blocks other command execution. Version, test, authorize, and observe it like application code.

Inspect every element returned by EXEC. A successful array reply can contain an error for one queued command while other commands have already changed data. A null reply with WATCH means the transaction did not execute because a watched key changed. If the connection is lost after sending EXEC, the client may not know whether the transaction ran, so recovery needs idempotency or a business-level reconciliation key.

Pipeline for round trips, not unlimited batches

Pipelining sends multiple commands before reading their replies. It can substantially improve throughput when network round-trip time dominates, but the server must queue replies until the client reads them. Use bounded batches, read every reply, and cap both request and response bytes. Ten thousand tiny increments and ten thousand multi-megabyte reads are not comparable batches.

A pipeline is not a transaction. Other clients can run commands between its operations. A partially broken connection can also leave the caller uncertain about which writes reached the server. Design idempotency and reconciliation where retry ambiguity matters.

Troubleshoot by symptom and boundary

Collect an evidence pack before changing configuration

redis-cli ... INFO server
redis-cli ... INFO clients
redis-cli ... INFO memory
redis-cli ... INFO persistence
redis-cli ... INFO replication
redis-cli ... INFO commandstats
redis-cli ... SLOWLOG GET 20
redis-cli ... LATENCY LATEST
redis-cli ... LATENCY DOCTOR
redis-cli ... MEMORY DOCTOR
redis-cli ... CLIENT LIST
redis-cli ... ACL LOG 20

Replace the ellipsis with the reviewed connection profile. Capture UTC time, endpoint, role, Redis version, and the reason for collection. Redact client addresses, names, usernames, keys, and command arguments when they contain customer or security data.

The slow log measures server command execution time and excludes client I/O. LATENCY events reflect enabled latency monitoring. MEMORY DOCTOR offers heuristics, not a substitute for byte-level capacity evidence. CLIENT LIST can be large and sensitive. Interpret every source within its boundary.

Distinguish large keys, hot keys, and a large keyspace

These are different incidents. A large key contains many members or bytes and can create command, network, deletion, persistence, and replication costs. A hot key receives disproportionate traffic and can saturate a single execution path even when it is small. A large keyspace contains many keys and increases expiry, scanning, metadata, persistence, and recovery work even if every value is modest.

Start with the application namespace and a bounded time window. Compare key count, value or member count, memory estimate, command frequency, reply bytes, TTL, and growth. Do not fetch a suspected large value merely to prove that it is large. Use type-specific cardinality commands such as HLEN, LLEN, SCARD, ZCARD, and XLEN before requesting members.

Hot-key detection depends on the eviction policy and available tooling. The --hotkeys mode relies on LFU counters, so it is not a universal hot-key detector. Application tracing, client-side command metrics, proxy evidence, or controlled sampling may be required. Confirm that diagnostic sampling will not expose key names or customer identifiers.

When a key is too large, repair the producer and data model before deleting the symptom. Bound collection growth, trim streams and lists with explicit retention semantics, divide independently accessed data, and set expiry where the data contract permits. Deleting one key without controlling its writer simply schedules the next incident.

Read counters as rates and correlate one timeline

Most INFO counters accumulate across process lifetime. The value of evicted_keys, expired_keys, rejected_connections, keyspace_hits, or a command call counter is less useful than its change over a known interval. Capture two samples with timestamps and calculate a rate. Record the Redis uptime so a restart is not mistaken for a sudden improvement.

Put application releases, traffic changes, failovers, backups, snapshots, AOF rewrites, host pressure, network events, and configuration changes on the same UTC timeline. A rising application p99 with stable server execution time points away from slow commands. A latency event aligned with a background save, fork, or disk stall suggests a different experiment from a single expensive command.

Hit rate needs context. Calculate hits divided by hits plus misses over the same interval, then compare origin load and user latency. An improved hit rate can still be harmful when a few huge values increase network time or when aggressive caching makes invalidation unreliable. Treat every ratio as one part of the workload contract.

Automate checks without creating a second failure

A shell loop that runs a harmless command once can become expensive when a scheduler launches it on every node every second. Automation needs an explicit endpoint inventory, timeout, concurrency limit, retry budget, secret source, output limit, and owner. It must distinguish a connection failure from a Redis error and a valid empty result.

redis-cli -h redis.internal -p 6379 \
  --user redis_observer --askpass -e --raw \
  INFO replication

--askpass is interactive and therefore unsuitable for an unattended job. The example shows the desired operator behavior, not a complete scheduled script. For automation, inject a protected secret at runtime, prevent shell tracing, avoid printing the environment, and destroy the job context after use. Never commit a URI containing credentials.

Set a connection timeout appropriate to the check and apply an outer job timeout so a stuck socket does not accumulate processes. Bound returned bytes before passing output to another tool. Preserve stderr and the exit code separately from stdout. If the parser depends on a field or reply format, test it against every supported Redis release and RESP mode.

Do not automate remediation directly from a single Redis counter. Require corroborating evidence, a cooldown, a maximum action frequency, and a stop condition. A script that restarts Redis whenever latency rises can convert a recoverable client or network problem into repeated dataset loads and availability loss.

Select the backup method before writing a script

A backup is complete only when it has an owner, timestamp, source endpoint and role, Redis version, persistence mode, file inventory, size, digest, encryption decision, off-host destination, retention, alert for staleness, and a successful isolated restore result.

Use the Redis 8.10 online BACKUP workflow

Redis 8.10 adds the BACKUP command family. It creates a self-contained, online backup while writes continue and works whether or not normal AOF persistence is enabled. The sealed result contains a BASE snapshot, an incremental AOF file, and a standalone manifest. Keep the established RDB and multipart-AOF procedures below for Redis releases that do not provide this command family.

Confirm support and prepare the destination

redis-cli --user backup_agent --askpass INFO server
redis-cli --user backup_agent --askpass COMMAND INFO BACKUP
redis-cli --user backup_agent --askpass CONFIG GET dir backupdirname backup-sealed-ttl
redis-cli --user backup_agent --askpass BACKUP STATUS

Proceed only when the installed server reports the command and the backup state is idle. The directory named by backupdirname is resolved below the Redis working directory and must be empty before BACKUP START. Confirm free space, filesystem ownership, the off-host destination, encryption, retention, and the administrator ACL before opening the backup window.

Start, observe, seal, copy, and clean up

redis-cli --user backup_agent --askpass BACKUP START
redis-cli --user backup_agent --askpass BACKUP STATUS
redis-cli --user backup_agent --askpass BACKUP LIST

redis-cli --user backup_agent --askpass BACKUP SEAL
redis-cli --user backup_agent --askpass BACKUP STATUS
redis-cli --user backup_agent --askpass BACKUP LIST

Wait for the state to become incrementing before sealing. During that state, BACKUP LIST exposes the immutable BASE file so a controlled data plane can begin copying it. After BACKUP SEAL, list the files again and copy all three reported paths, including the manifest, to one versioned off-host backup set. Record the source endpoint and role, Redis version, UTC start and seal times, file sizes, digests, configuration and ACL versions, and application recovery point.

Verify every copied digest before cleanup. Then release the pinned server-side artifacts:

redis-cli --user backup_agent --askpass BACKUP CLEANUP
redis-cli --user backup_agent --askpass BACKUP STATUS

If a pending, snapshotting, or incrementing backup must be cancelled, use BACKUP ABORT, preserve the reported error, and correct the cause before retrying. A sealed backup uses BACKUP CLEANUP, not abort. A nonzero backup-sealed-ttl can remove sealed files automatically, so the copy job and failure alerts must complete within the reviewed retention window.

Restore the sealed set in isolation

Copy the BASE, INCR, and manifest into a protected restore directory on an isolated compatible Redis host. Verify the inventory and digests, then configure the startup-only preload path to the copied manifest:

preload-file aof:/restore-staging/appendonly.aof.manifest

Start the isolated server with no application traffic, follow its log and INFO persistence through loading, and verify database size, representative keys and TTLs, modules, functions, and business invariants. Record the actual recovery point and restore time. Do not point preload-file at the active server-side backup directory, and do not make production the first restore test.

RDB backup script with success and integrity checks

The following example is intentionally strict. It expects the deployed data directory and RDB filename as protected job configuration rather than discovering paths with a broadly privileged Redis user. Inject REDISCLI_AUTH from the scheduler’s secret facility, never from a committed file. Test the script on a non-production instance and set a timeout that matches the real dataset.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

: "${REDIS_HOST:?Set REDIS_HOST}"
: "${REDIS_PORT:=6379}"
: "${REDIS_USER:?Set REDIS_USER}"
: "${REDISCLI_AUTH:?Inject REDISCLI_AUTH securely}"
: "${REDIS_DATA_DIR:?Set REDIS_DATA_DIR}"
: "${REDIS_RDB_FILE:=dump.rdb}"
: "${BACKUP_ROOT:?Set BACKUP_ROOT to an explicit backup directory}"

redis=(redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" \
  --user "$REDIS_USER" --no-auth-warning --raw -e)

role="$("${redis[@]}" ROLE | sed -n '1p')"
test "$role" = master || {
  echo "Refusing backup: expected writable primary, found $role" >&2
  exit 1
}

before="$("${redis[@]}" LASTSAVE)"
"${redis[@]}" BGSAVE SCHEDULE

deadline=$((SECONDS + 900))
while :; do
  info="$("${redis[@]}" INFO persistence | tr -d '\r')"
  after="$("${redis[@]}" LASTSAVE)"
  if [ "$after" -gt "$before" ] \
    && grep -q '^rdb_bgsave_in_progress:0$' <<<"$info" \
    && grep -q '^rdb_last_bgsave_status:ok$' <<<"$info"; then
    break
  fi
  [ "$SECONDS" -lt "$deadline" ] || {
    echo "Timed out waiting for a successful BGSAVE" >&2
    exit 1
  }
  sleep 2
done

stamp="$(date -u +%Y%m%dT%H%M%SZ)"
destination="$BACKUP_ROOT/$stamp"
source_file="$REDIS_DATA_DIR/$REDIS_RDB_FILE"

install -d -m 0700 "$destination"
install -m 0600 "$source_file" "$destination/dump.rdb"
redis-check-rdb "$destination/dump.rdb"
sha256sum "$destination/dump.rdb" > "$destination/SHA256SUMS"
printf 'endpoint=%s:%s\nlastsave=%s\n' \
  "$REDIS_HOST" "$REDIS_PORT" "$after" > "$destination/METADATA"

The LASTSAVE pattern follows the Redis-documented way to confirm that a requested background save completed successfully. The script refuses an unexpected replica because a lagging copy can violate the intended recovery point. If the runbook intentionally backs up a replica, change the role guard only after adding offset and lag acceptance checks.

Copy the completed directory to the approved off-host destination, verify the digest again after transfer, apply retention only to the explicit backup root, and alert when the latest verified backup exceeds its age objective. Never delete old backups before the new one passes validation and transfer.

Create a remote RDB with redis-cli

umask 077
redis-cli -h redis.internal -p 6379 \
  --user backup_agent --askpass \
  --rdb redis-20260804T130000Z.rdb

redis-check-rdb redis-20260804T130000Z.rdb
sha256sum redis-20260804T130000Z.rdb

redis-cli --rdb is useful when the backup host cannot read the Redis data directory. It initiates an RDB transfer through the replication protocol, so treat it like a full synchronization: schedule it, monitor fork memory, CPU, network, persistence, latency, and competing replica syncs. The example uses --askpass interactively. An unattended job needs protected secret injection.

redis-cli --functions-rdb can retrieve an RDB containing functions without keys on supported releases. It is not a replacement for the dataset backup. Record the server and client versions for either mode.

Back up multipart AOF safely

Redis 7 and later store AOF state as multiple files in appenddirname. A valid backup needs the manifest and every referenced base and incremental file. Copying only a filename from an older tutorial is incomplete.

1. Read and record dir, appenddirname, appendonly, and auto-aof-rewrite-percentage.
2. Set auto-aof-rewrite-percentage 0 for the controlled backup window. Do not start BGREWRITEAOF.
3. Poll INFO persistence until aof_rewrite_in_progress is 0. Also check the latest rewrite status.
4. Copy or archive the complete append directory, including its manifest. Keep paths, ownership, and permissions in the backup metadata.
5. Restore the previous automatic rewrite percentage immediately and verify the effective value. Persist the temporary change only when the restart runbook requires it, then persist the restored value as well.
6. Verify file inventory, sizes, digests, off-host transfer, and an isolated load test.

Hard-link staging can reduce the rewrite-disabled window on a compatible filesystem, as documented by Redis, but it needs a tested script and filesystem behavior. Do not assume that a copied directory is consistent if a rewrite overlapped it.

Validate RDB and AOF files before restore

redis-check-rdb /restore-staging/dump.rdb
redis-check-aof /restore-staging/appendonlydir/appendonly.aof.manifest

Run validation against a protected working copy, not the only backup. redis-check-rdb validates an RDB; it is not a magic data-repair tool. A successful file check proves format integrity, not that the snapshot contains the required business state.

Run redis-check-aof without --fix first and inspect the reported offset. Before any repair, preserve the complete original AOF set. redis-check-aof --fix can discard the AOF portion from an invalid point onward, which may cause substantial data loss. With multipart AOF, follow the exact installed-version procedure and keep the manifest with its referenced files. Prefer an isolated load and business reconciliation over blind in-place repair.

Restore an RDB or AOF step by step

1. Create an isolated Redis target with the required Redis version, modules, configuration, filesystem capacity, and no application traffic.
2. Preserve the target’s existing data directory before changing it. Confirm the exact directory, owner, group, permissions, RDB filename, AOF directory, and service unit.
3. Validate the backup file inventory and digest. Run redis-check-rdb or the applicable AOF validation against a working copy.
4. Stop the isolated target cleanly. Place the selected RDB or complete AOF set into the configured location with the Redis service ownership and restrictive permissions.
5. Make persistence mode match the backup being restored. When both AOF and RDB are enabled, Redis loads AOF because it is normally more complete. Do not place an old AOF beside a desired RDB and expect the RDB to win.
6. Start Redis and follow the service log and INFO persistence through loading. Stop if Redis reports truncation, corruption, a missing module, or incompatible encoding.
7. Verify role, Redis version, DBSIZE per logical database, representative key types and TTLs, stream pending state, functions, ACL expectations, and application-level invariants.
8. Measure restore time and record the actual recovery point. Only then plan a controlled application cutover, keeping the previous environment recoverable.

Never first-test a restore by replacing the active production data directory. A backup that has not loaded in isolation is an assumption.

Export, restore, and migrate individual keys

DUMP returns Redis’s serialized value for one key without its TTL. Capture TTL separately, then use a binary-safe transfer:

redis-cli -h source.internal --user migration_agent --askpass \
  -D "" --raw DUMP 'cache:user:42' > cache-user-42.dump

redis-cli -h target.internal --user migration_agent --askpass \
  -X dump_payload RESTORE 'cache:user:42' 900000 dump_payload REPLACE \
  

The 900000 TTL is milliseconds and is an example, not the original TTL. Capture PTTL immediately before export and decide how transfer time affects expiry. Omit REPLACE unless overwrite is explicitly approved. Verify type, value or cardinality, TTL, memory, and application behavior on the target.

MIGRATE transfers keys directly between Redis servers and, unless COPY is used, removes successfully transferred keys from the source. It can use authentication and multiple keys, but it is an active data move with timeout, TLS, routing, Cluster-slot, and partial-completion concerns. Use it only through a rehearsed migration plan with source and target evidence.

Use redis-cli --pipe for controlled mass insertion

redis-cli --pipe reads raw Redis protocol from standard input and sends commands efficiently. Plain lines copied from a terminal are not a robust mass-import format. Generate valid RESP with a tested producer, bound the batch, retain the source artifact and record count, and inspect the final error count.

generate_resp_from_reviewed_input \
  | redis-cli -h target.internal -p 6379 \
      --user import_agent --askpass --pipe --pipe-timeout 60

The placeholder producer must be implemented for the actual input schema and escaped bytes. Run the import against a disposable target first. Confirm key namespaces, slot tags, TTLs, duplicate policy, memory budget, eviction behavior, persistence load, replication lag, and rollback before production.

Additional Redis utilities for administrators

Reserve dangerous commands for controlled procedures

A repeatable CLI incident workflow

1. State the symptom in application terms, including scope, start time, and affected operations.
2. Confirm environment, endpoint, TLS mode, ACL user, database or Cluster, and current role.
3. Collect read-only server, client, memory, persistence, replication, latency, and command evidence.
4. Separate client pool, network, server execution, memory, persistence, and topology hypotheses.
5. Choose one controlled change with an owner, expected signal, stop condition, and rollback.
6. Run the same verification that exposed the problem, including application p99 and errors.
7. Keep or reverse the change based on evidence, then preserve the commands and outputs in the incident record.

The best cheat sheet does not make commands faster to type. It makes the operator slower to assume, faster to isolate the real boundary, and less likely to damage evidence. Use the related Linux Server Support service when Redis, systemd, kernel, firewall, and host evidence must be reviewed together.

Official Redis references

• Redis CLI
• Redis configuration
• Redis command reference
• Redis data types
• Redis keys and incremental iteration
• Redis transactions
• Redis pipelining
• Redis key eviction
• Redis latency monitoring
• Redis persistence, backup, and AOF recovery
• Redis ACLs
• Redis slow log