# Runbook Scaling Event > Use when performing runbook scaling event — application scaling procedure covering trigger assessment, scale execution, and monitoring. Use for manual scaling in response to traffic spikes, planned events, or autoscaling failures. - Skill: `cloudthinker-ai/runbook-scaling-event` (Agent Skill) - Install (CLI): `npx skillmds@latest add cloudthinker-ai/runbook-scaling-event` - Raw SKILL.md: https://api.skillmd.com/api/skills/cloudthinker-ai/runbook-scaling-event/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: cloudthinker-ai (https://skillmd.com/u/cloudthinker-ai) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/cloudthinker-ai/runbook-scaling-event --- # Application Scaling Runbook Skill Scale **{{ service_name }}** from **{{ current_capacity }}** to **{{ target_capacity }}**. Trigger: **{{ scaling_trigger }}** ## Workflow ### Phase 1 — Trigger Assessment ``` TRIGGER ASSESSMENT ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SCALING REASON Service: {{ service_name }} Trigger: {{ scaling_trigger }} Urgency: [IMMEDIATE / PLANNED / PROACTIVE] CURRENT METRICS Requests per second: ___ CPU utilization (avg/p95): ___% / ___% Memory utilization (avg/p95): ___% / ___% Response latency (p50/p95/p99): ___ms / ___ms / ___ms Error rate: ___% Queue depth (if applicable): ___ Active connections: ___ CAPACITY ANALYSIS Current: {{ current_capacity }} Target: {{ target_capacity }} Scale factor: ___x Estimated headroom after scaling: ___% AUTOSCALER STATUS [ ] Is autoscaler enabled? YES / NO [ ] Autoscaler current status: [scaling / steady / disabled] [ ] Why is manual scaling needed? [ ] Autoscaler too slow for traffic ramp [ ] Autoscaler at max limit [ ] Autoscaler misconfigured [ ] Proactive scaling for known event ``` ### Phase 2 — Pre-Scale Checks ``` PRE-SCALE CHECKS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ RESOURCE AVAILABILITY [ ] Sufficient compute quota for target capacity [ ] Sufficient IP addresses in subnet(s) [ ] Container image available and pullable [ ] Node capacity available (K8s) or instances launchable (EC2/VM) [ ] Load balancer can handle additional backends DEPENDENCY CHECK [ ] Database connection pool can handle additional instances Current pool: ___ / ___ max After scaling: ___ / ___ max [ ] Cache capacity sufficient for additional load [ ] Downstream services can handle increased throughput [ ] Rate limits on external APIs will not be exceeded [ ] Shared resources (file locks, queues) can handle concurrency COST ESTIMATE Additional cost: $___/hour ($___/month if sustained) Budget approval: [not needed / approved / pending] ``` ### Phase 3 — Scale Execution ``` SCALE EXECUTION ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KUBERNETES: [ ] Update replica count: kubectl scale deployment {{ service_name }} --replicas=___ [ ] Or update HPA limits: max replicas = ___ [ ] Watch rollout: kubectl rollout status deployment/{{ service_name }} EC2 / VM AUTO SCALING: [ ] Update ASG desired capacity: ___ [ ] Update ASG max capacity (if needed): ___ [ ] Verify launch template / configuration is current SERVERLESS: [ ] Update provisioned concurrency: ___ [ ] Update reserved concurrency: ___ EXECUTION LOG Scale initiated at: ___ New instances/pods started: ___ All instances healthy at: ___ Time to full scale: ___ minutes ``` ### Phase 4 — Post-Scale Monitoring ``` POST-SCALE MONITORING (check at T+5min, T+15min, T+1h) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CAPACITY VALIDATION [ ] All new instances/pods in Ready state [ ] New instances passing health checks [ ] Load balanced evenly across all instances [ ] No pending pods / failed launches PERFORMANCE METRICS (compare to pre-scale) Metric Before After Target ─────────────── ───────── ───────── ───────── RPS ___ ___ ___ CPU (avg) ___% ___% < 70% Memory (avg) ___% ___% < 80% Latency (p95) ___ms ___ms < ___ms Error rate ___% ___% < 1% DEPENDENCY HEALTH [ ] Database connections stable (not approaching pool limit) [ ] Cache hit ratio maintained [ ] Downstream services not overwhelmed [ ] No increased error rates from dependencies ``` ### Phase 5 — Scale-Down Plan ``` SCALE-DOWN PLAN ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SCALE-DOWN CRITERIA Scale down when: [ ] Traffic returns below ___ RPS for > ___ minutes [ ] CPU utilization < ___% for > ___ minutes [ ] Planned event has concluded [ ] Autoscaler can manage remaining load SCALE-DOWN PROCEDURE [ ] Reduce capacity gradually (not all at once) [ ] Step 1: reduce to ___x (50% reduction) [ ] Monitor for 15 minutes [ ] Step 2: reduce to target steady-state: ___ [ ] Verify performance remains within SLA [ ] Re-enable autoscaler (if was overridden) ESTIMATED SCALE-DOWN TIME: ___ ``` ### Phase 6 — Documentation ``` DOCUMENTATION ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ ] Log scaling event: Service: {{ service_name }} From: {{ current_capacity }} -> To: {{ target_capacity }} Trigger: {{ scaling_trigger }} Duration at elevated scale: ___ Cost impact: $___ [ ] Update autoscaler configuration if limits were insufficient [ ] Create ticket to improve autoscaling (if manual was needed) [ ] Update capacity planning with observed traffic patterns ``` ## 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 scaling event report with: 1. **Scaling summary** (service, trigger, from/to capacity) 2. **Pre-scale assessment** (metrics, dependencies, cost) 3. **Execution log** with timing and instance health 4. **Post-scale metrics** comparison (before vs. after) 5. **Scale-down plan** with criteria and schedule 6. **Recommendations** for autoscaler improvements