Skip to main content
Regulaxy

Collisions

Two maintenance windows approved separately that together break something — the four collision kinds, and how the wizard warns about them in advance.

A collision is two planned events whose windows overlap in time, with a relationship between them that makes the overlap dangerous. Each was approved separately and looked reasonable on its own.

One calculation feeds three places: the collisions tab in system connections, the warning in the scheduling wizard and the event editor, and the alerts bell.

Four kinds

Row headingWhen it is produced
Shared system · Connected systemsBoth events touch the same system, or two systems with a recorded connection between them
Cluster redundancyBoth events update hosts of the same cluster — taking more than one failure out of it at the same time
Host and its guestsOne event updates a hypervisor while another updates machines running on it: they are evacuated off it while their own reboot is in flight
Storage under maintenanceA storage system takes its controllers through a failover while servers whose volumes sit on it are being updated

The kinds are not a widening of one rule — they are different questions. "Systems that talk to each other" and "hosts that back each other up" are two different facts, and one pair of events can produce several rows, one per question.

What the row says

Not a severity word — the arithmetic:

Cluster VC-PROD-01 will run on 3 of 5 hosts between 23:00 and 03:00

Beside it: both events by name, type and hours, and the exact overlap. A storage row also carries the derived change window — how long the upgrade itself takes, from the controller count and the failover duration — with the derivation laid out for checking. The derivation is collapsed by default: the sentence is the finding, the arithmetic is the evidence.

Every row links through to the calendar.

Scan horizon

A selector at the top of the list: 7, 30, 60 or 90 days ahead. The default is 60.

The warning in the wizard

In the date step, and in the editor of an existing event, an amber bar appears the moment the chosen window collides. It:

  • Does not block. You can proceed and save. The screen says so explicitly: "You may continue — this is a warning only. Coordinating with the managers of the connected systems is recommended." The other direction, where a secondary service cancels an action the user already approved, is worse.
  • Is debounced while typing, rather than running on every keystroke.
  • Cannot take the wizard down. If the check failed for any reason nothing is shown — and no error is shown that nobody can act on.
  • An event being edited does not collide with itself.

Updated

This page is the file content/docs/en/v1/assets/collisions.mdx