Outcome
By the end of this lesson, you will be able to configure force-on and force-off overrides with appropriate expiry and reason fields and verify the override is active.
| Prerequisites | L1 |
| Time | 10 minutes |
1. Concept
An override has four parts.
Two you must give: a type, meaning what it does, and an expiry, meaning when it stops. One is optional: a reason, for whoever reads this later. The fourth is the target: you pick either one resource or a whole group in the Create Override form.
One note on the reason. It is stored with the override and shown in its notifications, but nothing validates or enforces it, so write it for the human who will find this override next week, not for a machine.
Field 1: Type
Two options:
- Force-on (
force_on): the resource (or group) stays ON during the window. Schedule stop crons are ignored. - Force-off (
force_off): the resource (or group) stays OFF during the window. Schedule start crons are ignored.
There is nothing finer than that. ON or OFF, nothing in between. This matches the scheduler’s vocabulary; complex state transitions (e.g., “scale to X replicas”) use the autoscaler features, not overrides.
Field 2: Reason
Free-form text. Optional. When provided, the reason is the operational documentation:
GOOD REASONS BAD REASONS─────────────────────────────────────────────────────────"Acme demo Sat 2pm, exp Mon 8am" "test""Incident #2026-05-19-payments, "weekend" prevent schedule firing""Migration to new instance types, "asked by sarah" expected 6h duration" ─── (no context)"DR drill, force-on all dev for 24h window"When provided, the reason becomes the answer to “why is this on?” when a future engineer is investigating. Be specific.
The reason is optional. It is stored with the override and included in the override notification when you give one, but it is not validated. Treat it as a note for teammates, not a control you can audit against. Writing a clear reason is a good habit, not a requirement.
Field 3: Expiry
Required, and it must be in the future. The override ends automatically at the expiry time. No exceptions.
EXPIRY OPTIONS Date and time: 2026-05-26 08:00 (picked from a calendar, shown in the target's schedule timezone) Quick presets: 1h, 4h, 12h, 1d, 3d, 7d (computed from now)The expiry is stored as an absolute UTC timestamp. Timezone conversions happen at display time only.
The expiry must be in the future, and that is the only check on it: there is no maximum duration. A team that sets a 90-day override gets one, so ask whether a change that long should be a schedule edit instead. L4 covers the full set of rules that make ZopNight accept or reject an override.
Field 4: Target
- Resource: pick one scheduled resource from the candidate list → applies to that one resource only
- Group: pick one scheduled group → applies to every member of the group
The candidate list only offers what can be overridden: scheduled resources and groups. A resource that is in a group shows as “Part of group X: override the group instead” and cannot be picked on its own.
Group overrides are more common for the demo / maintenance / incident scenarios. Per-resource overrides are for highly-specific situations (one VM needs to stay on for a specific test).
What the override does internally
WHEN YOU CREATE IT: - ZopNight sends the forced action right away: force-on starts the resource, force-off stops it (history shows "override:force_on" or "override:force_off")
WHEN A CRON FIRES on a resource with an active override: - If force-on and the cron is a stop → cron is SKIPPED - If force-off and the cron is a start → cron is SKIPPED - If force-on and the cron is a start → cron fires (already on, no-op) - If force-off and the cron is a stop → cron fires (already off, no-op)
AT EXPIRY (or when cancelled early): - The override ends - ZopNight sends the opposite action: a force-on ends with a stop, a force-off with a start (history shows "override_expired:...") - Subsequent cron firings act normallyThe override DOES actively transition the resource, twice: once when it is created and once when it ends. The action at the end is always the opposite of the override; it does not check what the schedule wants at that moment. So pick an expiry inside the window where the schedule would already have the resource in that end state. A force-on is best set to expire during the schedule’s off hours.
Notifications
Setting an override fires a notification (to every channel subscribed to that event: see M1.6 L3):
Slack notification:─────────────────────────────────────────────────────────🔔 Override applied Resource: staging-eu-cluster Type: Force-on Reason: "Acme Corp demo Sat 2pm, requested by sarah@sales" Expires: 2026-05-26 08:00 Europe/London Set by: engineer@zopcloud.com─────────────────────────────────────────────────────────The notification lets the team see overrides happen in real time, even when they’re not the one who set them. Reduces “who set this?” confusion.
A second notification fires when the override expires:
🔔 Override expired Resource: staging-eu-cluster Originally set by: engineer@zopcloud.com Reason: "Acme Corp demo Sat 2pm" Schedule now resumes normal operationThe expiry notification confirms the override cleanup happened on time.
Configuration flow
Overrides tab → Create Override─────────────────────────────────────────────────────────CREATE OVERRIDE
Target type: ● Resource ○ Group Resource: [ staging-eu-cluster ▾ ] (scheduled only) Action: [ Force ON (prevent stops) ▾ ] Reason: [ ] (optional) Expires at: [ 2026-05-26 08:00 ] [1h][4h][12h][1d][3d][7d]
[Cancel] [Create]Three required choices (target, action and expiry) and one optional note. The form is short on purpose: overrides should be set quickly, not deliberated over.
2. Demo
A team setting a maintenance override:
INTENT: Maintenance on dev-cluster-1, expected 6 hours, want schedule not to interfere.
T+0 Overrides tab → Create Override → Resource: dev-cluster-1T+10 sec Fill in: Action: Force-off Reason: "Planned migration to graviton node types, expected 6h duration. Tracked in ticket DEV-4521." Expiry: 8 hours from now (buffer of 2h)
T+20 sec Apply override.
T+25 sec Slack notification fires.
T+25 sec ZopNight sends a stop (already stopped manually before maintenance, so nothing changes). Any scheduled start in the next 8 hours is skipped.
T+6 hrs Maintenance complete. Resource is restarted manually by the team. Override is still active: the resource is now running despite the force-off override. (The override prevents the SCHEDULE from acting, not from manual start.)
T+8 hrs Override expires automatically.T+8 hrs ZopNight sends the opposite action (a start; the resource is already running, so nothing changes).T+8 hrs Expiry notification fires. Schedule resumes normal operation.The override prevented schedule interference during maintenance without preventing manual control. The team kept agency over the resource.
3. Hands-on (6 min)
In a sandbox:
1. Pick a sandbox resource that has a schedule attached.2. Apply a force-off override: - Reason: "Test override: exploring the UI" - Expiry: +1h (one hour from now)3. Save.4. Verify the override appears: - In the Overrides tab list (Active) - If the resource was running, in its history as a stop triggered by "override:force_off"5. Verify the Slack notification (if configured) fires.6. Wait or trigger a cron firing during the override window: confirm the cron is skipped (the resource state doesn't change).7. Wait for expiry (or cancel early via L3 mechanics).8. Confirm the override cleans up.The hands-on takes longer than the 6 minutes if you wait for expiry. The mechanics are quick; the verification is what takes the clock.
Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. One resource already covered by a schedule.ASK "Keep the staging database up until Friday at 18:00, reason: release testing."CHECK the expiry came back set. An override with no expiry is the one that quietly costs you a month.Tools behind it: create_override (write, tier 2, reversible), list_overrides (read, Operate), get_override_candidates (read, Optimize). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
An override expires while a resource is in the “wrong” state for what the schedule would normally enforce. What happens?
A. The resource stays in its current state until the schedule’s next cron fires for that resource
B. The override is recreated, and keeps running for the same length of time again
C. An error fires, and the resource is left in whatever state it happened to be in
D. ZopNight sends the opposite of the override’s action, then the schedule’s crons take over
Show answer
Correct: D. Expiry is not just metadata. ZopNight emits a corrective action (stop for an expired force-on, start for an expired force-off), recorded as “override_expired”. After that, the schedule’s crons act normally.
Q2
A team sets an override on a scheduled resource that expires in 90 days. What happens?
A. The create is rejected for exceeding a 7-day cap
B. It is created, since there is no maximum duration
C. ZopNight warns and asks an admin to approve it
D. It is created but cut short after 7 days anyway
Show answer
Correct: B. ZopNight checks only that the expiry is in the future. That puts the judgement on the team: a 90-day exception is almost always a schedule edit, not an override.
Q3
A force-on override is active on a resource. The user manually clicks Stop. What happens?
A. The stop is rejected outright, since the override is currently forcing that particular resource on
B. The override is automatically removed
C. An error fires
D. The stop succeeds; the override prevents the SCHEDULE from acting, not the user from acting manually
Show answer
Correct: D. After the stop, the resource is off, but the override prevents the schedule from re-starting it during the override window. Overrides scope to schedule behavior, not to manual actions. The user keeps agency.
5. Apply
Override configuration:
- Automate → Schedules → Overrides → Create Override (pick a resource or a group), and see all active overrides
For managing existing overrides, continue to L3.