What the system does

Regulaxy coordinates maintenance windows on an internal network: who is updating what, when, and what else is planned that same night on a system that depends on it. The installation itself stays with whoever performs it — what the system manages is the coordination around it and the record left behind.

The life of a window

Stage	What happens
Scheduling	A wizard that walks through the update type, what it covers, who is responsible, when, which tasks go with it, and a summary before sending
Notification	A calendar invitation to the system manager and the contacts, an email, and a ticket in the ticketing system when one is connected
Execution	The event's status moves between Planned, In progress, Completed, Failed and Cancelled
Record	The update type's checklist is filled in afterwards, and changes to the event are kept in the log

The wizard has six steps, and one of them changes with the update type: the selection step can ask for servers, equipment or databases — or disappear entirely, when the update type has no such targets at all.

The one check that runs while the date is still being chosen, rather than after it, is the collision check: another window, in the same hours, on a system that talks to the one you picked. A warning that arrives after the invitation has gone out to thirty contacts is a report, not a warning.

What is in the system

Area	What it holds
Operations	The calendar, the scheduling wizard, event management, tasks and alerts
Information assets	Servers, systems, databases, equipment and the connections between them
Infrastructure	Virtualization, storage, cloud, containers and backup
Capacity management	Clusters, racks and sites, reclaimable capacity and scenario planning
Risk and recommendations	The vulnerability register, lifecycle (EOL/EOS), business impact and urgency ranking
Governance	Meeting summaries and presentations
Activity planning	The weekly activity board and the organizational memory around it
Settings	Configuration, roles and permissions, connections and support

What any one user actually sees depends on their permissions and on which integrations are connected at the site. An area with no data source behind it does not render an interface pointing at a service that is not there.

What the system does not do

Three limits, all deliberate — they shape everything else:

• It does not install updates. It decides when the window opens, tells the people who need to know, and records what happened. Whatever runs the installation today keeps running it.
• It does not write to the inventory sources. The list of servers, equipment and databases is read from sources other teams maintain, and only read. Details in Architecture.
• It makes no outbound internet call at runtime. No cloud, no telemetry, and no external address to open in the firewall.

Two languages, two roles

The interface exists in Hebrew and in English, chosen per user — see Hebrew and English. Access is divided into two built-in roles, administrator and operator, with additional roles definable above them — see Roles and who may do what.

Where to go next

• Core concepts — the words every other page assumes you know. Read this one first.
• The console layout — where things are, and how to get there quickly.
• Architecture — what the system is made of and how it behaves when a source is unavailable.
• Prerequisites — what to prepare before install day.