Set Up Schedule Overrides That Expire on Their Own

Every schedule eventually meets a night when someone needs the environment on. The expensive habit is to detach the resource from the schedule “for tonight” and never reattach it. An override solves the same problem with an end time built in. This page covers how overrides behave in ZopNight and how to set the guard rails before the first one is created.

How an override behaves

An override takes precedence over the schedule for a fixed window, on either a single resource or a resource group:

• Keep running forces the target on: it starts the target at once if it is stopped, and a scheduled stop does not fire during the window.
• Force stop forces it off: it stops the target at once if it is running, and a scheduled start does not fire. Useful when a shared test database must stay down during a migration.

Each override carries a reason, visible to teammates, and an expiry. When it expires, the override is cleared automatically and the schedule applies again. The expiry is interpreted in the timezone of the schedule attached to that resource or group, not in the organisation’s default timezone, so “until 23:00” means 23:00 where the schedule’s crons run.

Only one override can be active on a resource or group at a time. The UI blocks a second one before you submit, and the API rejects it with a conflict, which avoids two people extending the same environment to different times.

1. Agree how long an override should last

ZopNight has no maximum override duration: the only check is that the expiry is in the future, so nothing in the product stops an override being set for weeks and quietly replacing the schedule. Agree a team convention instead, covering your longest legitimate case (a release weekend, say) and no more; a request longer than that is a sign the schedule’s hours are wrong.

2. Decide who can create overrides

Overrides are their own permission in ZopNight’s role model, separate from schedules. The built-in Viewer role is view-only, so viewers cannot create them. A custom role can include the override permission without schedule editing rights, and team-scoped access limits a member to the resources assigned to their team, so a team can extend its own environments without touching anyone else’s. See setting up RBAC for scheduling.

3. Create an override

1. Open the resource or resource group that follows the schedule.
2. Choose Keep running or Force stop.
3. Enter the reason, for example “release 4.12 smoke tests”.
4. Set the expiry, which must be in the future, and confirm. The override acts as soon as you confirm.

The overrides list then shows it with a relative countdown (“expires in 5h”).

4. Get told when overrides change

Subscribe a channel to the override events: set, cleared and expired. Routing these to the team channel makes an override a visible, shared decision rather than a private one. Slack, Microsoft Teams, Google Chat and generic webhooks are supported; see sending schedule alerts to Slack.

5. Review and clean up

The overrides list filters by status (active, expired or all), by target type (resource or group), by action (keep running or force stop) and by name. Cancel an override early when the work finishes so the next scheduled stop applies on time. The state history for each resource records whether a change came from a schedule, a user or an override, which is the evidence for a monthly look at who overrides most and whether their schedule needs new hours.

What an override does not do

It does not change the schedule itself, and it does not act on resources outside the one target. Related: cloud scheduling best practices.