Back to skills
SKILL.md
Runbook Os Patching
ASecurityUse when performing runbook os patching — oS patching window procedure covering pre-patch backup, patch application, reboot sequence, and validation. Use for scheduled maintenance windows, security patch deployments, or kernel upgrades.
- 6 stars
- 0 votes
- 0 copies
- 2 views
- Added September 8, 2026
Security analysis
100/100npx -y skills add cloudthinker-ai/CloudSkills --skill runbook-os-patching --agent claude-codeAre you the author of Runbook Os Patching?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-runbook-os-patching)---
name: runbook-os-patching
enabled: true
description: |
Use when performing runbook os patching — oS patching window procedure
covering pre-patch backup, patch application, reboot sequence, and validation.
Use for scheduled maintenance windows, security patch deployments, or kernel
upgrades.
required_connections: []
config_fields:
- key: target_hosts
label: "Target Hosts / Group"
required: true
placeholder: "e.g., web-servers-prod, db-replicas-us-east"
- key: patch_type
label: "Patch Type"
required: true
placeholder: "e.g., security updates, kernel upgrade, full OS update"
- key: maintenance_window
label: "Maintenance Window"
required: true
placeholder: "e.g., 2026-03-20 02:00-06:00 UTC"
- key: reboot_required
label: "Reboot Required"
required: false
placeholder: "e.g., yes, no, conditional"
features:
- RUNBOOK
- INFRASTRUCTURE
---
# OS Patching Runbook Skill
Execute OS patching for **{{ target_hosts }}** during **{{ maintenance_window }}**.
Patch type: **{{ patch_type }}** | Reboot: **{{ reboot_required }}**
## Workflow
### Phase 1 — Pre-Patch Planning
```
PRE-PATCH PLANNING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HOST INVENTORY
Target group: {{ target_hosts }}
Total host count: ___
OS distribution: ___
Current kernel version: ___
Patching order: [rolling / blue-green / all-at-once]
PATCH REVIEW
[ ] List available patches and review changelog
[ ] Identify security-critical patches (CVE numbers)
[ ] Check vendor advisories for known issues
[ ] Verify patches tested in staging/dev environment
[ ] Confirm patch compatibility with running applications
[ ] Document patches to apply:
Package: ___ (current: ___ -> target: ___)
```
### Phase 2 — Pre-Patch Backup
```
PRE-PATCH BACKUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Create VM snapshots or AMI images of target hosts
Snapshot IDs: ___
[ ] Verify backups completed successfully
[ ] Confirm backup restoration procedure is documented
[ ] Record current system state:
- Uptime: ___
- Running services: ___
- Open connections: ___
- Disk usage: ___%
[ ] Export current package list (dpkg --list / rpm -qa)
[ ] Save current kernel parameters (sysctl -a)
```
### Phase 3 — Rolling Patch Execution
```
PATCH EXECUTION (rolling — one batch at a time)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FOR EACH BATCH:
PRE-PATCH
[ ] Remove host(s) from load balancer / service discovery
[ ] Drain active connections (wait for in-flight requests)
[ ] Verify host removed from traffic rotation
[ ] Stop non-essential services
APPLY PATCHES
[ ] Update package index (apt update / yum check-update)
[ ] Apply patches (apt upgrade / yum update)
[ ] Record packages updated: ___
[ ] Check for held-back packages or conflicts: ___
[ ] Resolve any dependency issues
REBOOT (if {{ reboot_required }}):
[ ] Initiate graceful reboot
[ ] Wait for host to come back online
[ ] Verify new kernel version: ___
[ ] Verify boot completed without errors (check dmesg, journal)
POST-PATCH
[ ] Verify all critical services started
[ ] Run application health checks
[ ] Re-add host to load balancer / service discovery
[ ] Confirm traffic flowing to patched host
[ ] Monitor for 10 minutes before proceeding to next batch
BATCH PROGRESS:
Batch 1: [ ] patched [ ] validated [ ] in rotation
Batch 2: [ ] patched [ ] validated [ ] in rotation
Batch 3: [ ] patched [ ] validated [ ] in rotation
```
### Phase 4 — Post-Patch Validation
```
POST-PATCH VALIDATION (all hosts)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SYSTEM HEALTH
[ ] All hosts reporting healthy in monitoring
[ ] Kernel version consistent across fleet: ___
[ ] No unexpected service restarts
[ ] System logs clean (no new errors in syslog/journal)
[ ] Disk usage within normal range
APPLICATION HEALTH
[ ] All services running and passing health checks
[ ] Response times within baseline
[ ] Error rates at or below pre-patch levels
[ ] Cron jobs and scheduled tasks executing normally
[ ] SSL/TLS certificates still valid and serving
SECURITY VALIDATION
[ ] Vulnerability scan confirms patches applied
[ ] No new open ports or changed firewall rules
[ ] Security agent (if any) running and reporting
```
### Phase 5 — Rollback Procedure
```
ROLLBACK (if issues detected)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trigger: [service failure, performance degradation, boot failure]
Steps:
1. [ ] Remove affected host from load balancer
2. [ ] Restore from snapshot: ___
3. [ ] Verify host boots with previous kernel
4. [ ] Verify services start correctly
5. [ ] Re-add host to load balancer
6. [ ] Document rollback reason for retry planning
```
### Phase 6 — Cleanup and Documentation
```
CLEANUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Remove old snapshots after stabilization period (48-72h)
[ ] Update CMDB / inventory with new OS versions
[ ] Update patching documentation and runbook
[ ] Close change management ticket
[ ] Report patching compliance status
[ ] Schedule next patching window: ___
```
## 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 an OS patching execution report with:
1. **Patching summary** (hosts, patch type, window, kernel versions)
2. **Backup confirmation** with snapshot IDs
3. **Batch execution log** with per-host results
4. **Post-patch validation** results (system and application health)
5. **Issues and rollbacks** (if any occurred)
6. **Compliance status** (patched vs. total hosts)
Attribution
Related skills
View all in devops →Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.