Deploy Windows
A deploy window restricts when a service is allowed to build and deploy — a change window, business hours, or a weekend freeze. Windows are set in an explicit timezone and keep the wall-clock time you chose across daylight-saving changes. Configure one on a project, and its services inherit it; override it on any individual service.
Outside its window, a deployment is queued, not rejected. It waits, shows why it is waiting and when it will run, and dispatches itself the moment the window opens — nobody has to be awake for it. If several requests pile up during a freeze, only the most recent one runs: deploying a week-old commit at 22:00 on Tuesday is almost never what anyone meant.
Nothing changes until you configure one
No project or service is restricted by default. Deploy windows are entirely opt-in.
Recovery is never delayed
Rollbacks, restores, and automatic repair of a drifted service always run immediately. A change window exists to control when new change lands — not to prolong an outage.
You can always override
Anyone with permission to deploy can push through a closed window for a single deployment. The override is written to the audit log, so a freeze stays accountable rather than absolute.
# Show the windows in force for a service
$ zensailor service window show <service-id>
# Weeknights, 22:00 to 04:00 Paris time
$ zensailor service window set <service-id> \
--timezone Europe/Paris --cron "0 22 * * 1-5" --duration 360
# Deploy immediately, even if the window is closed
$ zensailor service deploy <service-id> --now