Skip to main content

Reboot Policy

Cloudaware provides a framework for customers to decide when and how instances must be rebooted safely after patching.

Use this guide to learn how reboots are handled in Cloudaware Patch Management.

Goals​

Reboot behavior should:

  • Preserve service availability by avoiding unnecessary or poorly timed restarts.
  • Ensure correctness and security by applying required reboots when kernel or core component changes demand it.
  • Be predictable and auditable so that owners know when to expect interruptions.

When Reboots Are Typically Required​

Reboots are usually required when:

  • Kernel updates or low-level driver changes have been installed.
  • Core system libraries or components that do not support live reload have been updated.
  • The OS or vendor explicitly marks a patch as requiring a reboot.

Cloudaware relies on OS-level behavior and vendor guidance to determine when a reboot is needed. Patch Management does not invent its own reboot rules on top of those signals.

Use these general patterns when designing reboot behavior:

  • Patch groups and waves – Use patch groups and canary waves so that only a subset of hosts reboots at a time.
  • Cluster-aware sequencing – For clustered or highly available services, reboot one node at a time and verify health before proceeding.
  • Environment order – Reboot in the same Dev → Stage → Prod progression described in Recurrence & Cadence.
  • Maintenance windows – Schedule reboots within defined maintenance windows and avoid critical business periods.

Reboot Methods​

The following reboot methods are available:

Immediate Reboot After Patching Maintenance​

This is the default method. Instances are rebooted immediately after patching maintenance is completed.

Custom-Order Reboot​

The reboot is performed in a custom order defined by instance tags. To use a custom reboot order, apply the following tags:

cloudaware:PatchingMaintenance = CustomReboot cloudaware:PatchGroup = 1 to 6

Patch groups are rebooted one at a time at 30-minute intervals. For example, instances tagged with cloudaware:PatchGroup = 2 will be rebooted after instances tagged with cloudaware:PatchGroup = 1, and so on. This allows you to control the reboot order based on your application requirements.

If the cloudaware:PatchGroup tag is present but has no value, the instance defaults to Patch Group 1.

Tag example: cloudaware:PatchingMaintenance = CustomReboot cloudaware:PatchGroup = 1

No Reboot​

If the cloudaware:PatchingMaintenance tag is set to NoReboot, patching is performed without a reboot. In this case, the instance owner must perform the reboot manually.

note

After patching, Cloudaware will reboot Linux machines only once.

Tags for Rebooting (Examples)​

Cloudaware uses the following custom tags and values to manage reboots:

cloudaware:PatchingMaintenance = NoReboot cloudaware:PatchingMaintenance = Exclude cloudaware:PatchingMaintenance = CustomReboot cloudaware:PatchingMaintenance = UpToDate cloudaware:PatchGroup = 1, 2, 3, 4, 5, 6

See also: Ad-hoc patching

Verification After Reboot​

After any reboot triggered by patching:

  • Confirm that the host is healthy at the OS level (CPU, memory, disk, network).
  • Run application-level checks to verify that critical user journeys and background jobs work as expected.
  • Where patches address vulnerabilities, perform post-reboot verification and vulnerability re-scans.

See the Monthly Windows Patching playbook for concrete examples.

Handling Failures and Rollbacks​

If a rebooted host shows degraded behavior:

  • Treat it as a failure in line with Retries & Timeouts configuration.
  • Decide whether to continue with the current wave or pause remaining jobs.
  • Use documented rollback procedures if you need to revert a patch release.
On this page