Runbook Cache Flush

---
name: runbook-cache-flush
enabled: true
description: |
  Use when performing runbook cache flush — cache flush and warm procedure
  covering impact assessment, flush execution, and warming strategy. Use when
  cache data is stale, after schema changes, or when cache corruption is
  suspected.
required_connections: []
config_fields:
  - key: cache_service
    label: "Cache Service"
    required: true
    placeholder: "e.g., Redis production cluster, Memcached"
  - key: cache_endpoint
    label: "Cache Endpoint"
    required: true
    placeholder: "e.g., redis-prod.internal:6379"
  - key: flush_scope
    label: "Flush Scope"
    required: true
    placeholder: "e.g., full flush, specific key pattern user:*"
  - key: reason
    label: "Reason for Flush"
    required: false
    placeholder: "e.g., stale data after migration, cache poisoning"
features:
  - RUNBOOK
  - DATABASE
---

# Cache Flush and Warm Runbook Skill

Execute cache flush for **{{ cache_service }}** at **{{ cache_endpoint }}**.
Scope: **{{ flush_scope }}** | Reason: **{{ reason }}**

## Workflow

### Phase 1 — Impact Assessment

```
IMPACT ASSESSMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CACHE PROFILE
  Service: {{ cache_service }}
  Endpoint: {{ cache_endpoint }}
  Flush scope: {{ flush_scope }}
  Current memory usage: ___ MB / ___ MB total
  Key count: ___
  Hit ratio (current): ___%

DOWNSTREAM IMPACT
[ ] Identify services dependent on this cache
[ ] Estimate cache-miss penalty (latency increase): ___ ms
[ ] Estimate origin load increase: ___x multiplier
[ ] Check origin (database/API) can handle thundering herd
[ ] Estimate time to rebuild cache organically: ___ minutes

RISK ASSESSMENT
[ ] Can origin handle 100% cache-miss traffic? YES / NO
[ ] Is there a read-through cache pattern in place? YES / NO
[ ] Will flush cause user-visible latency increase? YES / NO
[ ] Is there a risk of cache stampede? YES / NO
```

### Phase 2 — Pre-Flush Preparation

```
PREPARATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Notify dependent service owners
[ ] Scale up origin (database / API) if needed
    - Current capacity: ___
    - Target capacity: ___
[ ] Enable rate limiting on cache-miss path (if available)
[ ] Configure circuit breaker thresholds (if available)
[ ] Take cache snapshot / RDB backup (if full flush)
[ ] Open monitoring dashboards:
    - Cache hit/miss ratio
    - Origin service latency and error rate
    - Application response times
[ ] Confirm maintenance window with stakeholders
```

### Phase 3 — Flush Execution

```
FLUSH EXECUTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TARGETED FLUSH (preferred — specific keys/patterns):
1. [ ] Identify keys to flush: {{ flush_scope }}
2. [ ] Count keys matching pattern: ___
3. [ ] Delete keys using SCAN + DEL (never use KEYS in production)
4. [ ] Verify target keys removed
5. [ ] Confirm non-target keys intact

FULL FLUSH (use only when necessary):
1. [ ] Final confirmation: full flush approved by ___
2. [ ] Execute FLUSHDB or FLUSHALL
3. [ ] Record flush timestamp: ___
4. [ ] Verify memory freed: ___ MB

POST-FLUSH METRICS
  Key count after flush: ___
  Memory after flush: ___ MB
  Timestamp: ___
```

### Phase 4 — Cache Warming Strategy

```
CACHE WARMING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WARMING APPROACH (select one):
[ ] Passive warming — let read-through rebuild cache naturally
[ ] Active warming — run warming script to pre-populate hot keys
[ ] Hybrid — warm critical keys actively, let others rebuild passively

ACTIVE WARMING STEPS (if selected):
1. [ ] Identify hot keys from previous access patterns
2. [ ] Run warming script / job:
    - Target key count: ___
    - Batch size: ___
    - Rate limit: ___ keys/second
3. [ ] Monitor warming progress: ___% complete
4. [ ] Verify warmed data correctness (spot-check samples)

WARMING PROGRESS
  Hit ratio target: > ___%
  Current hit ratio: ___%
  Estimated time to target: ___ minutes
```

### Phase 5 — Post-Flush Validation

```
POST-FLUSH VALIDATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CACHE HEALTH (check at T+5min, T+15min, T+1h)
[ ] Cache hit ratio recovering: ___% -> ___% -> ___%
[ ] Memory utilization trending back to normal
[ ] No eviction pressure (if memory-limited)
[ ] Connection count stable

APPLICATION HEALTH
[ ] Response times returning to baseline
[ ] Error rate at or below pre-flush level
[ ] No timeout errors from cache layer
[ ] Origin load decreasing as cache warms

ORIGIN HEALTH
[ ] Database CPU / connections returning to normal
[ ] API backend latency returning to normal
[ ] No connection pool exhaustion events
```

### Phase 6 — Cleanup

```
CLEANUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Scale down origin if it was scaled up
[ ] Remove temporary rate limits or circuit breaker overrides
[ ] Confirm cache hit ratio at steady state: ___%
[ ] Notify stakeholders of completion
[ ] Document flush results and lessons learned
[ ] Update cache TTL policies if stale data was the root cause
```

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce a cache flush execution report with:
1. **Flush summary** (service, scope, reason, timestamps)
2. **Impact assessment** results and risk mitigations applied
3. **Flush execution** confirmation with before/after metrics
4. **Warming progress** tracking and hit ratio recovery curve
5. **Validation results** (application and origin health)