| name | 05-production-operations |
| description | Use when preparing or auditing a live app after deployment. Checks logging, uptime monitoring, health checks, alerts, error tracking, backups, disaster recovery, abuse protection, and audit logs. |
Production Operations
Mission
Ensure production is visible and recoverable. Deploy is the beginning, not the end. A production system needs logging, monitoring, alerts, error tracking, backups, disaster recovery, rate limiting, and audit evidence.
Use when
- The app is live or about to go live.
- The user asks about production readiness, monitoring, alerts, health checks, Sentry, backups, incident response, or uptime.
Workflow
1. Verify health checks
Search:
rg -n 'health|/api/health|status.*ok|uptime|db.*ok|ready|readiness|liveness' app pages src server 2>/dev/null
A minimum health endpoint should verify:
- API route responds;
- database can be reached;
- critical dependencies are not obviously down;
- returns 200 for healthy, 503 for degraded.
2. Verify uptime monitoring
Check documentation/config for:
- UptimeRobot, Better Uptime, Vercel checks, Pingdom, Statuspage, custom cron, or equivalent.
- Monitors for
/, /api/health, and critical user journeys.
- Alert threshold and notification channel.
3. Verify structured logging
Search:
rg -n 'console\.log|console\.error|logger|pino|winston|logtail|datadog|axiom|event:|requestId|userId' app pages src server 2>/dev/null
Required for important events:
- auth events,
- payment/subscription events,
- failed API calls,
- admin actions,
- destructive actions,
- background jobs,
- rate-limit denials.
Logs must not include tokens, raw passwords, full card data, or unnecessary PII.
4. Verify alerting
Required alerts:
- downtime;
- high error rate;
- response time above threshold;
- paid API/billing anomaly;
- database connection failures;
- backup failure;
- critical Sentry errors.
Alert channels must be known and tested.
5. Verify error tracking
Search:
rg -n 'Sentry|captureException|ErrorBoundary|error\.tsx|global-error|unhandledrejection|uncaughtException' app pages src server 2>/dev/null
Required:
- frontend and backend error tracking;
- global error boundary;
- sanitized user-facing messages;
- critical error alerts;
- release/version tags if possible.
6. Verify backups and restore
Required:
- database plan identified;
- automatic backups understood;
- external backup for important production data;
- restore tested;
- uploads/storage backup if used;
- RPO/RTO agreed with client.
Never assume a provider backup is enough if restore has not been tested.
7. Verify abuse protection
Search:
rg -n 'Ratelimit|rateLimit|429|captcha|hcaptcha|recaptcha|Retry-After|firewall|WAF' app pages src server 2>/dev/null
Rate limits required for:
- login/signup/reset;
- AI/paid API endpoints;
- public forms;
- sensitive public APIs.
8. Verify audit logs
Search:
rg -n 'audit_log|auditLog|activity_log|admin_action|created_by|updated_by|deleted_by|actor|event_type' app pages src server db prisma supabase 2>/dev/null
Audit logs should be append-only for critical actions.
Output contract
# Production Operations Report
## Production visibility
## Monitoring and alerts
## Error tracking
## Backup and disaster recovery
## Abuse protection and audit logs
## Findings
| Severity | Evidence | Risk | Fix | Verification |
|---|---|---|---|---|
Stop criteria
Stop and escalate if production data exists and there is no backup/restore path, or if a live paid API endpoint can be abused without limits.
