Hosting Operator Checklists

Checklists do not replace judgment. They protect routine work from memory, interruption, and stress. Adapt these to the actual platform, assign ownership, and link each item to the relevant dashboard or runbook.

Daily Operations

• Review active critical and warning alerts.
• Confirm overnight backups completed and remote copies transferred.
• Review backup verification, prune, garbage-collection, and replication failures.
• Check mail queues, unusual outbound volume, and reputation warnings.
• Review disk, inode, thin-pool, and backup-repository free space.
• Check failed RAID members, drive warnings, power supplies, fans, and environmental sensors.
• Review unresolved customer-impacting and abuse tickets.
• Confirm monitoring freshness and notification transport health.
• Review changes scheduled for the next 24 hours.
• Record any issue that should be watched on the next shift or review.

Weekly Operations

• Review operating-system and platform update status.
• Investigate repeated alerts and noisy thresholds.
• Review certificate and domain expirations within the next 60 days.
• Check resource growth and forecasted days to full.
• Review hypervisor cluster, quorum, storage, and replication health.
• Review network errors, optical levels, interface flaps, and sustained utilization.
• Confirm configuration backups for routers, switches, firewalls, and load balancers.
• Review failed login trends and privileged-access changes.
• Check open vendor cases, hardware replacements, and facility tickets.
• Update documentation for material changes completed during the week.

Monthly Operations

• Perform at least one documented restore test.
• Review backup retention and independent-copy status.
• Review capacity across compute, storage, network, power, rack, ports, IPs, and licenses.
• Audit privileged accounts, stale users, API keys, and multi-factor authentication.
• Review lifecycle dates for operating systems, control panels, hypervisors, hardware, and firmware.
• Inspect the highest-growth customers and workloads.
• Review abuse trends and recurring compromise causes.
• Test out-of-band access to a representative set of critical devices.
• Review emergency contact, carrier, facility, vendor, and remote-hands information.
• Close or reassign long-running exceptions and temporary rules.
• Review customer-facing status and incident communication templates.

Maintenance Window

Before

• Change record identifies purpose, scope, owner, schedule, risk, and expected impact.
• Backups or configuration snapshots are current.
• Out-of-band or console access has been tested.
• Cluster, storage, network, and monitoring are healthy before the change.
• Dependencies and affected customers are identified.
• Success tests and rollback criteria are written.
• Required packages, firmware, licenses, media, and credentials are available.
• Customer and internal notices are scheduled.
• No conflicting backup, migration, update, or facility work is running.

During

• Record start time and actual steps.
• Change one failure domain at a time where possible.
• Watch console, logs, monitoring, and customer-facing checks.
• Pause when actual behavior differs from the plan.
• Do not continue merely because the window is closing.
• Apply rollback when criteria are met.

After

• Validate from internal and external viewpoints.
• Confirm redundancy has returned to normal.
• Confirm backups and monitoring cover the changed system.
• Review failed services, warnings, and unexpected configuration drift.
• Send completion or extended-impact communication.
• Update diagrams, inventory, and runbooks.
• Record follow-up work and lessons learned.

Server Migration

Discovery and preparation

• Domains, DNS zones, mail routing, databases, applications, jobs, and integrations inventoried.
• Source and destination runtime versions compared.
• Destination storage includes transfer, extraction, and rollback space.
• New server is patched, backed up, monitored, and documented.
• External allowlists, callbacks, licenses, and IP restrictions identified.
• DNS TTL changes completed far enough in advance.
• Representative test workloads migrated and validated.
• Customer communication and rollback deadline approved.

Cutover

• Application writes, jobs, and queues placed in controlled state.
• Final file, database, and mailbox synchronization completed.
• DNS, routing, NAT, proxy, or service ownership changed.
• TLS, web, login, database, upload, background job, API, and mail workflows tested.
• Monitoring and backup jobs report from the destination.
• Source system restricted but preserved for rollback.

Closure

• Transfer warnings and differences resolved.
• Customer validation obtained where required.
• Old DNS, monitoring, backup, license, and automation references removed.
• Final source archive retained according to policy.
• Old data sanitized after the rollback period.
• Inventory and diagrams updated.

Restore Test

• Test objective and workload selected.
• Restore point chosen without using production data paths accidentally.
• Encryption keys and credentials obtained through the documented process.
• Isolated destination network and storage prepared.
• Start time recorded.
• Files, database, VM, or account restored without overwriting production.
• Boot, filesystem, database integrity, application login, and background jobs tested.
• External dependencies safely simulated or disabled.
• Completion time and effective restore throughput recorded.
• Missing secrets, configs, licenses, and documentation recorded.
• Test environment securely removed.
• Runbook and RTO assumptions updated.

Alert Response

• Acknowledge and assign the alert.
• Confirm monitoring data is fresh and the condition is real.
• Identify customer and redundancy impact.
• Check related devices, power, network paths, logs, and recent changes.
• Open an incident channel or ticket when thresholds are met.
• Apply the relevant runbook or safe containment action.
• Escalate to vendor, carrier, facility, or additional operator early enough.
• Communicate status and next update time.
• Validate service externally after the alert clears.
• Adjust alert rule, dependency, or documentation when the response reveals a gap.

Security or Abuse Incident

• Incident owner, severity, and affected services identified.
• Reporter, evidence, timestamps, and IP ownership validated.
• System clocks and timezone assumptions confirmed.
• Relevant logs, snapshots, process state, and configuration preserved.
• Ongoing harm contained using the narrowest effective control.
• Credentials, tokens, keys, and sessions rotated or revoked as needed.
• Entry point and persistence investigated.
• Known-clean data or software restored.
• Customer, upstream, facility, legal, or law-enforcement contacts engaged according to policy.
• Recovery monitored for recurrence.
• Evidence stored with access controls and handling record.
• Post-incident actions assigned and tracked.

Data-Center Deployment

Before shipping or travel

• Rack space, depth, rails, power, connectors, and circuit capacity confirmed.
• Equipment, serials, asset labels, firmware, and burn-in tests complete.
• Switch ports, VLANs, IPs, BGP, DNS, and cross-connects prepared.
• Out-of-band addresses, credentials, licenses, and VPN access prepared.
• Cables, optics, rails, screws, labels, tools, and spares packed.
• Facility access, loading, escort, and remote-hands procedures confirmed.
• Front/rear elevation and cable plan prepared.

Installation

• Asset and rack position verified before mounting.
• A/B power supplies connected to intended independent feeds.
• Network and management cables connected to labeled ports.
• Both ends of cables labeled.
• Airflow and cable service loops checked.
• Power, hardware health, management controller, and console tested.
• Production and management paths tested independently.
• Photographs and rack records updated.

Before leaving or closing remote hands

• Monitoring and alerts active.
• Backups or configuration backups active.
• Redundancy and failover tested within the approved scope.
• Unused packing materials and temporary cables removed.
• Spare parts stored and inventoried.
• Facility ticket, circuit IDs, and installation notes recorded.

Monthly Capacity Review

• Compute allocation and measured peak reviewed.
• One-node or one-component failure state calculated.
• Storage free space, thin provisioning, latency, and growth reviewed.
• Backup repository growth, retention, prune, and verification reviewed.
• Transit, peering, internal links, errors, and failover utilization reviewed.
• Rack units, A/B power, PDU outlets, switch ports, optics, and IP addresses reviewed.
• License, subscription, warranty, and vendor-support limits reviewed.
• Ticket volume, alert burden, and manual provisioning work reviewed.
• Procurement and circuit lead times updated.
• Action thresholds and expansion owners assigned.
• Expected, high-growth, failure, and supplier-delay scenarios reviewed.