Server Maintenance Checklist Template

Phase 1: Health & Alerts

Runs every time. The run type and host mix recorded here decide which later phases appear. The last task shows only for groups with cloud instances.

• Open the run and record the server group and run type — weekly, monthly or quarterly, and whether the group includes physical servers or cloud instances
• Review every alert raised since the last run — each one resolved or ticketed; silenced alerts need an owner and an end date
• Check services, scheduled tasks and cron jobs — everything expected is running and the last scheduled run succeeded
• Compare CPU, memory and swap with the baseline — a steady climb matters more than today’s value
• Confirm monitoring and endpoint protection agents are reporting — a silent agent looks exactly like a healthy server
• Check the provider’s scheduled maintenance and retirement notices — a retirement date means a planned move now or an unplanned outage later

Phase 2: Storage & Capacity

• Check free space on every volume against thresholds — for example warn at 80% and act at 90%, and project the date each volume fills at its current growth rate
• Clear only what the retention rules allow — rotated logs, temporary files, installer caches and old crash dumps
• Check database transaction log growth — a log that never shrinks usually means log backups are failing
• Check VM snapshots against the retention policy — old snapshots keep growing, slow the host and are not backups
• Ticket anything that will fill within 90 days — or add it to the capacity plan with an owner

Phase 3: Logs, Backups & Time

• Review security and system logs for anomalies — failed logons, new admin rights, service crashes, disk and hardware events
• Confirm logs reach the central store and meet retention — CIS Controls v8.1 sets a minimum of 90 days
• Check backup job results for every server in the group — record the date of the last good backup, not just last night’s status
• Check that new servers and volumes are in a backup job — coverage gaps open when servers are built, not when they fail
• Confirm time sync against at least two sources — clock drift breaks Kerberos authentication and log correlation
• Raise a ticket for every failure before closing the run — a finding without a ticket number is forgotten by next week

Phase 4: Access & Security Hygiene

Shown on monthly and quarterly runs.

• Confirm this month’s patch cycle was signed off for the group — list any server on an open patch exception; the patching itself is not done from here
• Review local and privileged accounts — remove leavers and disable accounts dormant for 45 days
• Review service accounts and scheduled task credentials — each has an owner, a purpose and a known password or key age
• Compare listening ports and installed services with the build baseline — anything new needs an explanation or removal
• Confirm endpoint protection is current — definitions updated and no unresolved detections

Phase 5: Expiry Dates & Records

Shown on monthly and quarterly runs.

• Check TLS certificate expiry dates — renew anything expiring within 30 days; public certificates issued now last at most 200 days
• Check software licences and support contracts — raise renewals with enough lead time for procurement
• Check operating system end-of-support dates — Windows Server 2016 extended support ends in January 2027, so its upgrade or retirement needs a plan now
• Check DNS records and domain registrations for hosted services — stale records and lapsed domains break services quietly
• Update the server record — owner, role, dependencies and last maintenance date in the CMDB or asset register

Phase 6: Quarterly Review

Shown on quarterly runs only.

• Confirm each server still has a business owner and a purpose — servers nobody claims go to decommissioning
• Check configuration drift against the hardening baseline — manual fixes made during incidents tend to stay
• Review the quarter’s capacity trends — and the resizing or purchases needed in the next twelve months
• Review monitoring thresholds and alert noise — alerts nobody acts on teach people to ignore alerts
• Confirm runbooks and recovery notes are current — they should describe the server as it runs today, not as it was built
• Confirm this quarter’s restore test is booked or done — the test runs in its own checklist; this task only checks that it happened