No-Deploy Windows

No-deploy windows let you block deployments during recurring weekly periods. For example, use one to avoid deploying during a Monday morning traffic spike, or during a weekly batch job.

Configuring windows

On a project’s Settings page, under No-Deploy Windows:

1. Set the project’s timezone (an IANA name like Europe/Amsterdam; defaults to UTC). All windows for the project are interpreted in this timezone, regardless of the server’s own timezone.
2. Add one or more windows: a day of the week, a start time, and an end time (both in HH:MM, 24-hour).

A project can have multiple windows, on the same or different days. Each is checked independently: a deploy is blocked if the current time falls inside any configured window.

What’s blocked

Manual deploys, webhook-triggered deploys, and API deploys are all blocked while a window is active. Attempting one returns an error:

deploys are paused by a no-deploy window (Monday 10:00–12:00 Europe/Amsterdam); next allowed at 12:00

• A manual deploy click shows this as a flash message.
• A webhook or API deploy request gets it back as a 403 JSON response.

What’s allowed

Rollbacks always bypass no-deploy windows. A rollback is a recovery action, not a forward deploy, so it’s never blocked. That includes the automatic rollback triggered by a failed health check.

Fail-open behavior

If Conveyor can’t read the configured windows for a project (a transient database error), it logs an error and allows the deploy rather than blocking it. A failed window check should never silently block a deploy that nothing is actually configured to block.

See How Deployments Work for what a deploy actually does once it’s allowed to proceed.