Execute Clay incident response procedures with triage, mitigation, and postmortem. Use when responding to Clay-related outages, investigating errors, or running post-incident reviews for Clay integration failures. Trigger with phrases like "clay incident", "clay outage", "clay down", "clay on-call", "clay emergency", "clay broken".
Executes Clay incident response procedures for outages, errors, and postmortem reviews.
/plugin marketplace add jeremylongshore/claude-code-plugins-plus-skills/plugin install clay-pack@claude-code-plugins-plusThis skill is limited to using the following tools:
Rapid incident response procedures for Clay-related outages.
| Level | Definition | Response Time | Examples |
|---|---|---|---|
| P1 | Complete outage | < 15 min | Clay API unreachable |
| P2 | Degraded service | < 1 hour | High latency, partial failures |
| P3 | Minor impact | < 4 hours | Webhook delays, non-critical errors |
| P4 | No user impact | Next business day | Monitoring gaps |
# 1. Check Clay status
curl -s https://status.clay.com | jq
# 2. Check our integration health
curl -s https://api.yourapp.com/health | jq '.services.clay'
# 3. Check error rate (last 5 min)
curl -s localhost:9090/api/v1/query?query=rate(clay_errors_total[5m])
# 4. Recent error logs
kubectl logs -l app=clay-integration --since=5m | grep -i error | tail -20
Clay API returning errors?
├─ YES: Is status.clay.com showing incident?
│ ├─ YES → Wait for Clay to resolve. Enable fallback.
│ └─ NO → Our integration issue. Check credentials, config.
└─ NO: Is our service healthy?
├─ YES → Likely resolved or intermittent. Monitor.
└─ NO → Our infrastructure issue. Check pods, memory, network.
# Verify API key is set
kubectl get secret clay-secrets -o jsonpath='{.data.api-key}' | base64 -d
# Check if key was rotated
# → Verify in Clay dashboard
# Remediation: Update secret and restart pods
kubectl create secret generic clay-secrets --from-literal=api-key=NEW_KEY --dry-run=client -o yaml | kubectl apply -f -
kubectl rollout restart deployment/clay-integration
# Check rate limit headers
curl -v https://api.clay.com 2>&1 | grep -i rate
# Enable request queuing
kubectl set env deployment/clay-integration RATE_LIMIT_MODE=queue
# Long-term: Contact Clay for limit increase
# Enable graceful degradation
kubectl set env deployment/clay-integration CLAY_FALLBACK=true
# Notify users of degraded service
# Update status page
# Monitor Clay status for resolution
🔴 P1 INCIDENT: Clay Integration
Status: INVESTIGATING
Impact: [Describe user impact]
Current action: [What you're doing]
Next update: [Time]
Incident commander: @[name]
Clay Integration Issue
We're experiencing issues with our Clay integration.
Some users may experience [specific impact].
We're actively investigating and will provide updates.
Last updated: [timestamp]
# Generate debug bundle
./scripts/clay-debug-bundle.sh
# Export relevant logs
kubectl logs -l app=clay-integration --since=1h > incident-logs.txt
# Capture metrics
curl "localhost:9090/api/v1/query_range?query=clay_errors_total&start=2h" > metrics.json
## Incident: Clay [Error Type]
**Date:** YYYY-MM-DD
**Duration:** X hours Y minutes
**Severity:** P[1-4]
### Summary
[1-2 sentence description]
### Timeline
- HH:MM - [Event]
- HH:MM - [Event]
### Root Cause
[Technical explanation]
### Impact
- Users affected: N
- Revenue impact: $X
### Action Items
- [ ] [Preventive measure] - Owner - Due date
Run the triage commands to identify the issue source.
Determine if the issue is Clay-side or internal.
Apply the appropriate remediation for the error type.
Update internal and external stakeholders.
| Issue | Cause | Solution |
|---|---|---|
| Can't reach status page | Network issue | Use mobile or VPN |
| kubectl fails | Auth expired | Re-authenticate |
| Metrics unavailable | Prometheus down | Check backup metrics |
| Secret rotation fails | Permission denied | Escalate to admin |
curl -sf https://api.yourapp.com/health | jq '.services.clay.status' || echo "UNHEALTHY"
For data handling, see clay-data-handling.
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.