Description
Split from #4981 (mega-issue). When several maintenance windows cover one environment, the reporter needs to control order and gating between them:
we do all guest OS on a Hyper-V in one time slot, then the Windows Hyper-V host on a different rotation, or for a domain we reboot the DC first then all the other servers after … ideally you would have a dependency: if the first job has resulted in a server being offline, do not continue with the rest. To proceed with maintenance, conditions need to be met.
I suppose you could keep what you have but have a reboot priority and delay, so that you can set the order.
Today there is no ordering, priority, delay, or dependency concept on either maintenance implementation (config_policy_maintenance_settings, legacy maintenance_windows), and maintenanceRebootWorker issues reboots to every eligible online device in an active window on a 10-minute sweep with no sequencing.
Proposed Fix (for spec)
Minimum viable version, in order of value:
- Priority + stagger on a window:
rebootPriority (int) and staggerSeconds so devices in one window reboot in a deterministic order with a delay between batches (DCs before members, hosts after guests).
- Gate on the previous batch:
proceedOnlyIf: 'previous_batch_online' — the worker does not issue the next batch's reboots until every device of the previous batch has re-heartbeated (or a per-window timeout expires, which then raises an alert — see the post-window verification issue).
- Cross-window dependency (
dependsOnWindowId) is the full ask but can wait for the first two.
Design note: since maintenance is a config-policy feature, targeting should ride the existing assignment hierarchy plus dynamic device groups (config_policy_assignments.level = 'device_group' already works), not a new targeting model.
Affected Files
apps/api/src/jobs/maintenanceRebootWorker.ts (sequencing lives here)apps/api/src/db/schema/configurationPolicies.ts (configPolicyMaintenanceSettings)apps/web/src/components/configurationPolicies/featureTabs/MaintenanceTab.tsx
Reported By
stressedout9064 on Discord (#feature-suggestions, 2026-09-04) — split from #4981. Siblings: #5234 (recurrence options), #5236 (post-window verification), #4330.
Description
Split from #4981 (mega-issue). When several maintenance windows cover one environment, the reporter needs to control order and gating between them:
Today there is no ordering, priority, delay, or dependency concept on either maintenance implementation (
config_policy_maintenance_settings, legacymaintenance_windows), andmaintenanceRebootWorkerissues reboots to every eligible online device in an active window on a 10-minute sweep with no sequencing.Proposed Fix (for spec)
Minimum viable version, in order of value:
rebootPriority(int) andstaggerSecondsso devices in one window reboot in a deterministic order with a delay between batches (DCs before members, hosts after guests).proceedOnlyIf: 'previous_batch_online'— the worker does not issue the next batch's reboots until every device of the previous batch has re-heartbeated (or a per-window timeout expires, which then raises an alert — see the post-window verification issue).dependsOnWindowId) is the full ask but can wait for the first two.Design note: since maintenance is a config-policy feature, targeting should ride the existing assignment hierarchy plus dynamic device groups (
config_policy_assignments.level = 'device_group'already works), not a new targeting model.Affected Files
apps/api/src/jobs/maintenanceRebootWorker.ts(sequencing lives here)apps/api/src/db/schema/configurationPolicies.ts(configPolicyMaintenanceSettings)apps/web/src/components/configurationPolicies/featureTabs/MaintenanceTab.tsxReported By
stressedout9064 on Discord (#feature-suggestions, 2026-09-04) — split from #4981. Siblings: #5234 (recurrence options), #5236 (post-window verification), #4330.