Automating Redis Monitoring with an AI Agent: From Graphs to Fixes

Most teams running Redis will recognize this one. Friday evening, peak traffic. maxmemory fills, evictions jump from zero to thousands per second, the cache hit ratio craters, and every miss falls through to a database that was sized on the assumption the cache would absorb 90% of reads. The part that stings in the postmortem: the Grafana panel showed evictions climbing for three weeks. Everyone saw the graph. Nobody owned the action.

That gap, between Redis monitoring that shows you a problem and someone doing something about it, is what this part is about. Part one covered the metrics that matter: cache hit ratio, memory fragmentation, eviction behavior, slow commands, big keys and replication lag. Part two audited all of them with native tools: INFO, SLOWLOG, LATENCY, MEMORY DOCTOR and redis-cli --bigkeys.

If you ran that audit, you found real issues. You also spent hours on it, and the output was a snapshot. Fragmentation drifts, keyspaces grow, and one deploy can add a KEYS call that undoes a month of tuning. This part covers how CloudThinker runs that audit continuously and, unlike a dashboard, follows through with evidence-backed fixes you approve or reject.

---

Why graphs don't turn into fixes

The Friday-evening team had good monitoring. The failure was structural, and it shows up the same way in most Redis setups:

• Dashboards plot lifetime counters. evicted_keys and keyspace_hits are cumulative since restart. A graph built on them flattens a two-week regression into a gentle slope that never crosses a threshold.
• Each panel shows one metric. The eviction storm needed two facts together: 38% of keys had no TTL, and the policy was noeviction. They lived on different panels, or on none.
• Evidence expires. By the time someone looks, the slow log has rotated and the latency samples that explain Thursday's spike are gone.
• Nobody owns cache hygiene. Adding TTLs or splitting a big hash is real engineering work with no incident attached, so it waits for one.

An alert rule can't fix any of that. It fires on one number at one moment. What's missing is something that keeps the baseline, connects the numbers, and arrives with a proposed change.

---

Connecting Redis: a read-only ACL user, about five minutes

01Datastore

Redis

• Self-hosted RedisRedis 6.x and 7.x
• Redis CloudAll tiers
• Upstash RedisAll tiers, over TLS

Read-only ACL user

02Investigation

CloudThinker

• Keep the baselineINFO deltas, slow log, latency events
• InvestigateCorrelate drift with deploys and traffic
• Propose the fixTTLs, policy, key refactors, with evidence

Nothing installed on the node

03Where the team works

Chat and tickets

• Slack or TeamsFindings and approvals in the thread
• JiraRefactors filed with the slow-log evidence
• GrafanaYour dashboards stay where they are

Nothing new to watch

CloudThinker connects the way your security review would insist on: a dedicated Redis ACL user that can read but can't write or administer:

redis-cli ACL SETUSER cloudthinker-readonly on '>GENERATED_PASSWORD' '~*' \
  '+@read' '-@write' '-@dangerous' '-@admin'

+@read allows read commands, -@write denies SET, DEL and the rest of the write family, and -@dangerous and -@admin block FLUSHALL, CONFIG, DEBUG, SHUTDOWN and replication commands. Create the user, paste a redis://cloudthinker-readonly:<password>@<host>:<port> URL into CloudThinker (rediss:// for TLS), and the first scan starts. The whole flow takes about five minutes. The Redis connection guide has the exact rule and the platforms it covers: self-hosted Redis 6.x and 7.x, Redis Cloud and Upstash.

What CloudThinker watches

Once connected, CloudThinker runs the part-two audit on a loop instead of once a quarter:

1. Cache hit ratio. keyspace_hits against keyspace_misses, computed from deltas and trended, not eyeballed once. A ratio drifting from 92% to 84% over two weeks becomes a finding with a likely cause attached (new key pattern, TTL change, working set outgrowing maxmemory).
2. Memory fragmentation. mem_fragmentation_ratio per node, flagged when it holds above ~1.5, with the RSS-to-used-memory gap translated into wasted gigabytes.
3. Eviction and expiry behavior. The evicted_keys rate against your maxmemory-policy, including the dangerous quiet case: noeviction on a cache workload, which fails writes instead of evicting when memory fills.
4. Slow commands. SLOWLOG entries collected before they rotate out and lined up with latency spikes, with repeat offenders (a KEYS pattern in a cron job, an HGETALL on a giant hash) identified by client and frequency.
5. Big keys and hot keys. Sampled key-size analysis to catch the 800 MB hash before it becomes a blocking DEL or a replication stall.
6. Replication health. Replica lag and full-resync counts, so a replica quietly falling behind shows up before a failover makes it everyone's problem.

The checks are the ones you can run by hand. The difference is cadence and memory: CloudThinker has the baseline, so "fragmentation is 1.7" arrives as "fragmentation rose from 1.2 to 1.7 since the March 14 deploy."

---

One finding, investigated end to end

01Signal

Hit ratio drifts

From 92% to 84% over two weeks, measured as deltas, not lifetime totals.

02Hypotheses

Investigate

New key pattern, TTL change, or working set outgrowing maxmemory.

03Changes

Correlate

Line the drift up with deploys, evictions and keyspace growth.

04Output

Finding

The cause, the evidence, and a proposed fix that waits for approval.

Here's how the Friday-evening story plays out with the baseline in place (an illustrative example; key names and numbers are made up). On a Tuesday, three weeks before peak, the hit ratio delta for the last 24 hours reads 0.84, down from a steady 0.92. Before guessing, CloudThinker lists the readings and what each predicts:

Memory first. used_memory sits at 97% of maxmemory, and evicted_keys went from near zero to ~40 per second over nine days. That points at reading three, but it doesn't explain why the working set grew.

Keyspace next. INFO keyspace shows 5.0M keys with only 3.1M carrying an expiry, so 38% never expire. Sampling with SCAN and TYPE/TTL shows the no-TTL keys are concentrated in one prefix, pricing:quote:*, which didn't exist in the baseline from a month ago.

Changes. The first pricing:quote:* keys show up the day the pricing-service 3.2 release went out. Its quote cache writes without EX.

Policy. CONFIG GET maxmemory-policy returns allkeys-lru. So today Redis is evicting older session and catalog keys to make room for quotes that are never read twice. If someone "fixes" the evictions by switching to noeviction, Friday's peak turns them into failed writes instead.

Finding. Posted in the channel with each command's output attached: pricing:quote:* keys are written without a TTL since release 3.2, they're crowding out reusable keys, and the hit ratio will keep falling until they expire or memory grows. Proposed fixes, both waiting for approval: add EX 900 to the quote writes (a code change, filed to Jira with the evidence), and in the meantime run a throttled SCAN that sets a TTL on existing pricing:quote:* keys.

That's the Friday outage caught on a Tuesday, three weeks early, with a fix someone can approve in a minute.

What a first pass typically finds

The numbers below are illustrative, a composite first scan of a mid-market setup: one primary with a replica, around 12 GB of data, backing a SaaS API. Yours will differ.

Nothing exotic. The eviction storm from the opening is fully assembled in rows two and three: keys that never expire, plus a policy that fails writes instead of evicting. A dashboard shows each metric on its own. The table connects them, refreshes daily, and every row arrives with a proposed fix that waits for approval.

The fixes CloudThinker proposes

When it finds something, CloudThinker proposes a specific change with the reasoning attached:

• TTL strategy. If a large share of keys have no expiry, it identifies which key patterns they belong to, estimates the memory reclaimed by adding TTLs, and proposes values based on observed access recency.
• Eviction policy. If noeviction or a mismatched policy is causing failures or evicting the wrong keys, it proposes a policy (allkeys-lfu, volatile-lfu, volatile-ttl and so on) with the trade-offs for your workload spelled out, per the Redis eviction docs.
• Big-key refactors. For an oversized hash or set, it proposes the split (bucketed hashes, HSCAN instead of HGETALL) and quantifies the latency cost from the slow log.
• Fragmentation remediation. Active defragmentation settings or a scheduled replica-first restart, depending on your Redis version and topology.

Every proposal cites the underlying INFO, SLOWLOG and sampling data: the same evidence you gathered by hand in part two, minus the hours.

---

You decide what CloudThinker may touch

CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval. The finding above arrives with "set TTL on existing pricing:quote:* keys" as a proposal. Writes also need the connection user to have them: the read-only ACL user above can't run them at all until you grant a scoped write user.

Every finding, proposal, approval and change lands in an audit trail: what was observed, what was proposed, who approved, what changed, and when.

Why this beats the traditional setup

The deeper difference is ownership. A dashboard assumes someone will look, connect the panels and do the work. CloudThinker does the looking and connecting itself, and hands a person a decision instead of a graph.

---

Getting started

Ask in plain language. Every answer is grounded in your instance's actual data:

"Why did our cache hit ratio drop below 80% last week? Which key patterns are missing most?"

"Show me the ten biggest keys, which clients touch them, and what a refactor would look like. Propose only, change nothing."

"Evictions spiked at 21:00 yesterday. What got evicted, and is our maxmemory-policy right for this workload?"

"Which key prefixes have no TTL, and how much memory would we get back if they expired after an hour?"

What CloudThinker won't do

"AI agent connected to production Redis" should raise questions. Here are the answers:

• Read-only by default. The connection user has no write or admin commands. Remediation needs a scoped write user you grant explicitly, and the change still goes through Auto Mode.
• No surprise config changes, deletions or restarts. You decide which of those wait for a person.
• Nothing outside the audit trail. Every proposed and executed action is logged with its evidence and its approver.
• No architectural decisions. CloudThinker will show you that the session store shouldn't be one 890 MB hash. Whether to reshard it, move it or redesign sessions is your engineering call.

Think of it as your part-two audit running daily, with a remediation queue attached. Not an autopilot you hand CONFIG SET to on day one.

Related reading

• Redis monitoring: 6 metrics that decide if your cache is helping
• Redis monitoring with native tools: a hands-on performance audit
• Automating PostgreSQL performance tuning with an AI database agent
• Auto Mode: graduated autonomy with safe defaults

From watching graphs to closing findings

You know which Redis metrics matter and how to audit them by hand. What broke in the Friday-evening story wasn't knowledge or tooling. It was the follow-through. Continuous watching, findings with evidence, and fixes that go through Auto Mode close that gap: the eviction trend gets caught in week one, arrives with a fix, and someone approves it.

Try CloudThinker free with 100 premium credits and no card required, and follow the Redis connection guide to see your own first findings table within the hour.