How patch management works

Understand patch policies, rings, cycles and optional alert suppression during patching.

octoja keeps the operating systems on your managed devices up to date. Instead of pushing every update to every device at once, you roll updates out in controlled stages, review what installs, and carry approvals from healthy rollouts into the next ring. You describe the rollout once in a patch policy; octoja generates the work and installs only what you approve. Patch management covers Windows and macOS.

The building blocks

Four pieces make up a rollout.

Building block	What it is
Patch policy	The overall plan: which customers' devices it covers, the rings it rolls out through, and the rules for promoting updates between them.
Deployment ring	One stage of the rollout — for example a small pilot first, then the rest of the fleet. Each ring has its own device-matching rules, its own maintenance window, and its own restart behaviour.
Maintenance window	When a ring installs updates: a schedule plus how long the window stays open.
Patch cycle	One ring's scheduled maintenance occurrence — where you review and approve updates before they install.

How a rollout works

You create a policy, split its devices into rings, and give each ring a maintenance window.
octoja generates a patch cycle for each ring on its schedule, listing every pending update as Pending Review.
You review each update — Approve, Reject, or Defer — and finalize the cycle. If the policy approves by rule instead, that step happens on its own.
When the maintenance window opens, the agent installs the approved updates and reports the result of each one.
If auto-promotion is on and the completed ring's rollout meets its conditions, its update approvals are copied into a draft for the next ring. Review the destination cycle and click Finalize Cycle before it can install.

How rings choose which devices to patch

Each ring has rules that decide which devices belong to it. A device is patched by every ring whose rules it matches — octoja does not pick a single ring for you at install time. So give each ring a distinct set of devices (for example by tag, group, or operating system) so that every device falls into exactly one ring. A device that matches two rings is patched by both.

Ring order determines the destination of automatic or manual promotion: the next ring up. Each ring generates cycles on its own schedule. An approved cycle starts in its maintenance window even if the previous ring has not completed or has reported failures. Under Automatic approval, this applies independently to every ring. To wait for a successful pilot before a later ring runs, choose Manual approval, schedule its windows later, and finalize its cycle only after reviewing the pilot results.

Staging is optional. Turn Use deployment rings off and the policy stops being a sequence: every device it covers is patched together on one schedule, with one maintenance window and one restart behaviour.

One setting overrides ring membership entirely: a device in maintenance mode with Patches paused is handed no updates at all for as long as that lasts, whichever rings match it.

Note: The Update Catalog shows each device under a single ring to keep its per-ring counts readable. When a device matches several rings, the catalog lists it under the last one — the one furthest along the rollout. That display does not change which rings actually patch the device.

The patch cycle lifecycle

A patch cycle moves through a fixed set of states.

State	What it means
Draft	The cycle has been generated and is waiting for you to review its updates.
Approved	You have decided every update and finalized the cycle. It now waits for its maintenance window.
In Progress	The window is open and devices are installing.
Completed	The cycle has ended. Check the device and update results: a completed cycle does not prove that every update installed successfully.
Cancelled	The cycle was stopped before it ran.
Missed	The window opened and closed without the cycle ever starting — usually a draft nobody finalized in time. Nothing was installed.

Once an hour, octoja reconciles open regular cycles with the pending updates on their devices. Under Manual approval, new updates can appear as Pending Review without returning an approved cycle to Draft. Its existing decisions and scheduled start remain intact; newly discovered, unreviewed updates are not thereby approved. Policies with Automatic approval decide new updates by rule. Emergency cycles retain their explicitly selected update list.

A cycle that is still Draft when its maintenance window ends becomes Missed and installs nothing. A missed cycle is not retried: the ring picks up again at its next scheduled window, so anything still pending appears in the cycle after it. You can only reopen an approved cycle under Manual approval. Under Automatic approval, the rules own those decisions.

Auto-promotion between rings

After a cycle completes, auto-promotion copies its update approvals into a Draft for the next ring when the conditions are met. It does not approve the destination cycle. Decide any remaining Pending Review updates there and click Finalize Cycle. This also applies to a draft created by promotion in a policy with Automatic approval. If no destination draft exists yet, the next ring must have a schedule so octoja can create one.

Before promotion, the ring must clear the gate you set: a minimum success rate, a minimum number of devices that reported a result, and optionally no failures at all. The gate is checked per operating system independently, so a healthy Windows rollout is not held back by macOS results, and the reverse.

Maintenance windows and time zones

A maintenance window is a schedule plus a duration — four hours by default. A schedule can follow the calendar, or it can follow Microsoft's release rhythm: choose the Patch Tuesday at 02:00 template, then set Days after the reference Tuesday to shift a ring off that anchor. That is how you build a pilot on the day itself and the next ring a week later.

A window is evaluated in the policy's time zone and may run past midnight. Where a device does not recognise the policy's time zone, it falls back to its own local time, so its window can open at a different wall-clock hour than the schedule says.

Choose Time zone when creating a policy, including when using a template. The picker initially suggests your browser's time zone. You can change it in the policy editor; saving another setting does not silently replace the stored zone with the current browser zone.

Restart behaviour belongs to the ring: it decides whether octoja may restart a device when an update asks for one, how many restarts a run may spend, and how often a signed-in user may postpone that restart. See the setup guide for waiting periods and how operations already started finish.

With Automatic maintenance mode, a policy can suppress alerts during patch execution, at most until the patch window ends. The option is off by default. It pauses neither checks nor patches and leaves other maintenance windows unchanged. Separately configured maintenance with patches paused still applies.

A ring set to Run manually only (no schedule) generates no cycles on its own, so you patch it with an emergency cycle or by promoting updates into it from an earlier ring.

Windows and macOS together

A single policy patches a mixed Windows and macOS fleet. octoja works out each device's operating system and sends it only its own updates, so one ring and one cycle can cover both. Linux devices are not patched by patch management.

While a patch policy targets a Windows device, the agent suppresses automatic Windows updates between maintenance windows too. This is independent of whether you also block the Windows Update interface. During a connection outage, the last received state remains in effect. The agent returns update control only after successfully confirming that no policy targets the device anymore.

Keeping a specific update out

Sometimes one update should not install — a faulty driver, or a problematic update you are waiting to clear. Within a policy you can exclude it (by update, KB number, or category). A global block works by KB number, so it covers Windows updates: a blocked KB reaches no device anywhere in the instance, and it is barred from being promoted into a later ring. Give a block an end date and it lifts itself once that date passes; leave the date empty and it holds until you remove it. For macOS, a policy exclusion does the same job.

A policy can also keep updates out on its own judgement. Turn on Exclude updates with known problems and octoja withholds any update that currently carries an active problem report — an unresolved Microsoft known issue, a red or yellow community flag, or reports from other octoja users. The update starts flowing again by itself once the problem clears.

Exclusions, blocks, and known-problem holds are all honoured at the moment updates are handed to a device, even if a cycle already approved them.

Seeing what happened

The Update Catalog shows every update seen across your fleet and how far each one has progressed through the rings — how many devices have succeeded, failed, or missed it. It also marks the updates worth a second look: the ones you have blocked, and the ones carrying a known problem.

Each cycle has a results view with the per-device outcome, including reboots and any error reported. In a Windows run, every update also carries a Selection line saying why it was installed or left out, alongside the rules it satisfied, the exclusions it matched, and any blocked KB.

Permissions

Patch management uses four permissions, granted per group under Administration → Groups:

Permission	What it allows
Patch Policy Management	Create, edit, and delete patch policies and their exclusions, and manage global blocks.
Manage Patch Cycles	Decide the updates in a cycle and finalize it, and reopen, cancel, or force-promote a cycle.
Emergency Patch Cycles	Create an emergency cycle outside the normal schedule and outside the ring order.
View Patch Policies and Cycles	See patch policies, cycles, and results without making changes.

FAQ

Can I disable the Windows Update service when octoja manages updates?

No. octoja uses the Windows Update Agent to search for, download, and install Windows updates. Do not disable the Windows Update service (wuauserv). octoja does not replace the Windows Update components with its own installer.

A patch policy's suppression of automatic Windows updates is separate: it controls automatic update behaviour, but does not mean you should switch off the required service. Use the patch policy for that control.

Are Windows updates downloaded in advance always downloaded again?

octoja delegates downloading to the Windows Update Agent, then checks whether the update is downloaded for installation. This does not mean that every update is transferred in full again, nor that an existing download is always reused. A separate advance download therefore does not guarantee a shorter patch run or less network traffic.

Was this helpful?

Still need help? Ask the team