When you need an override

Outcome

By the end of this lesson, you will be able to distinguish overrides from manual actions and schedule edits and identify the three scenarios where override is the right tool.

1. Concept

Every team running a good schedule eventually needs it not to apply, just this once.

There are three ways to do that, and each is right in a different situation:

TOOL              WHEN                                  PERSISTENCE
─────────────────────────────────────────────────────────────────────
Manual action     One-shot start or stop, right now    Until next cron fires
Override          Suspend or force state for a window  Until expiry or cancel
Schedule edit     Permanent change to the hours         Until next edit

An override is the middle one, and it is for an exception with an end date. It either suspends the schedule or forces a resource on or off, for a window you name, and then it stops. The schedule carries on as before.

The three override scenarios

Scenario 1: A demo this weekend. Sales needs the staging environment to stay running over the weekend for a customer demo. The schedule normally stops staging at 8 PM Friday. The team:

• Adds a force-on override on the staging group
• Reason: “Customer demo for Acme Corp, scheduled for Saturday 2 PM”
• Expiry: Sunday 10 PM (a time when the schedule has staging off anyway)
• Result: The schedule’s stop cron is ignored for these resources during the window. The resources stay running. When the override expires, ZopNight stops them (the opposite of force-on), which matches the schedule, and the Monday 8 AM start cron brings them back.

The override expressed the intent precisely: temporary exception, documented reason, automatic cleanup.

Scenario 2: A planned outage. The team needs to do maintenance on a non-prod cluster. They don’t want the schedule to restart it mid-maintenance:

• Adds a force-off override on the cluster
• Reason: “Planned migration to new node types, expected duration 6 hours”
• Expiry: 8 hours from now (with buffer)
• Result: The schedule’s start cron is ignored during the window. Even if a scheduled start would normally fire, the override prevents it. After expiry, the schedule resumes.

Scenario 3: An incident needs non-prod up after hours. A production incident is ongoing, and the team needs the staging environment running overnight to reproduce it:

• Adds a force-on override on the staging group
• Reason: “Incident #2026-05-19-prod-payment-delay, reproducing in staging”
• Expiry: 12 hours
• Result: Any stopped member starts right away, and the schedule’s stop cron is ignored during the window. When the override expires (or is cancelled), ZopNight stops the group again and the schedule resumes.

Note that a force-on never “freezes” resources in their current state: creating it starts every targeted resource that is stopped.

Override vs. manual action

Manual actions (covered in M1.2 L4) are one-shot:

• Click Stop → resource stops now → next scheduled start fires normally
• Click Start → resource starts now → next scheduled stop fires normally

Manual action does NOT suspend the schedule. The next cron firing acts on the resource as expected.

Override differs:

• It actively suspends the schedule for a window
• It acts immediately: a force-on starts the resource now, a force-off stops it now
• The state during the window is enforced (force-on or force-off)
• The schedule’s crons do NOT fire on the resource during the window
• At expiry, ZopNight sends the opposite action (a force-on ends with a stop, a force-off with a start), then normal scheduling resumes

For Scenario 1 (demo weekend), a manual start wouldn’t help: the schedule would stop staging again Friday at 8 PM. Override force-on prevents that.

Override vs. schedule edit

Schedule edits are permanent. If the team needs to change staging’s hours for good (“we now run staging 24/7”), edit the schedule. If the change is for one weekend, override.

INTENT                              TOOL
─────────────────────────────────────────────────────
One demo weekend                    Override (force-on, expires Monday)
Permanent: keep staging 24/7        Schedule edit (remove stop crons)
This one-time maintenance window    Override (force-off, expires 8 hours)
Permanent: stop on Fri 6 PM         Schedule edit (change cron time)

The decision criterion: is the change reverting? Yes → override. No → schedule edit.

Why explicit expiry matters

An override without expiry is a forgotten override. Every team has stories of a force-on override set “for the weekend” that ended up running indefinitely. The resource stayed on for months past intent, burning cost the team thought they had saved.

ZopNight requires expiry on every override. This is not negotiable. Common patterns:

SCENARIO                         TYPICAL EXPIRY
─────────────────────────────────────────────────────
Weekend demo                     Sunday night, inside the schedule's off hours
Maintenance window               2x the expected duration (buffer)
Incident response                12-24 hours, extend if needed
Off-hours work session            End of session + 2 hours

There is no cap on how far out an expiry can be: ZopNight checks only that it is in the future (see L4). Anything longer than a few days is usually a schedule edit, not an override, so make that call yourself.

Per-resource vs. per-group override

Overrides can be set at either:

• Per-resource: for a single resource (e.g., one specific VM)
• Per-group: for every member of a group (e.g., all of “dev-platform”)

The choice is not entirely free. Only resources and groups that have a schedule attached can be overridden. A resource that belongs to a group cannot be overridden on its own: ZopNight tells you it is part of the group and to override the group instead. Resources on a read-only cloud account and empty groups are not eligible either, and each target can have only one active override at a time.

Per-group is the scaling pattern. For the demo weekend example, set one force-on override on the “staging” group rather than 23 separate per-resource overrides.

The reason field: why it matters

The reason is optional, but it is stored with the override and shown in override notifications. Always fill it in. It is the most operationally useful field on the override:

WITHOUT REASON                                 WITH REASON
─────────────────────────────────────────────────────────
"Why is staging still running                  "Why is staging still running
 on Saturday?"                                  on Saturday?"

"I don't know, override was set                 "Acme Corp demo Saturday 2pm,
 weeks ago by some engineer."                    expires Monday 8 AM. We're good."

Investigation needed.                            Investigation done in 5 seconds.

Treat the reason field like a commit message. Future-you (or the next engineer on call) will thank present-you for the context.

2. Demo

A typical override scenario walked through:

T+0       Sales rep emails: "Customer demo Saturday 2 PM, need staging
          running through Monday morning."

T+30 sec  Engineer opens ZopNight → finds the staging group.

T+45 sec  Click "Override" → fill in:
            Type:    Force-on
            Reason:  "Acme Corp demo Sat 2pm, requested by sarah@sales"
            Expiry:  Sunday 2026-05-25 22:00 (24-hour notation)

T+1 min   Save. The override is active.

T+1 min   Override appears in the Active list on the Overrides tab,
          with the time left until it expires.

T+1 min   Slack notification posts: "Override applied on group 'staging-eu'
          by engineer X. Expires Monday."

DAY 3 (Sunday night):
T+0       Expiry time hits.
T+1 min   ZopNight sends the opposite action: the staging resources stop,
          which is what the schedule wants on a Sunday night.

DAY 4 (Monday morning):
08:00     Schedule's normal Monday start cron fires. Resources start.
          Schedule operates normally going forward.

Two clicks to set up. Self-expiring. Documented. The pattern scales: 200 demos a year, 200 short overrides, no forgotten overrides.

3. Hands-on (5 min)

For your own estate (or a sandbox):

1. Identify a real or hypothetical scenario where override is the right
   tool (not a manual action, not a schedule edit).
2. Decide: force-on or force-off?
3. Write the reason (one sentence: what the override is for, who
   requested it).
4. Pick an expiry time. Choose realistically: when does the exception
   end?
5. (Optional, sandbox) Apply the override. Verify it appears on the
   Overrides tab. Verify the Slack notification fires.

For your real estate, do not apply unless the scenario is real.
Practice the decision; the apply is L2.

4. Knowledge check

Q1

A team needs staging to stay running this weekend for a customer demo. The right tool is:

A. Edit the schedule itself so as to remove both of the weekend stop crons entirely
B. Manually start the resources Saturday morning
C. Apply a force-on override on the staging group, expiring once the demo is over
D. Disable the schedule

Q2

A force-on override is set on a resource that has no schedule attached. What happens?

A. The override force-keeps the resource ON until expiry: even without a schedule, an override is a state assertion
B. The override does nothing
C. The override is rejected
D. The override quietly creates a brand new schedule of its own on that resource, replacing the existing one entirely

Q3

A team sets an override “for this weekend” without an expiry. What does ZopNight do?

A. Accepts it indefinitely, with no expiry at all being set
B. Rejects the override: expiry is required on every override
C. Sets expiry to 1 hour
D. Warns but accepts

5. Apply

Overrides live in:

• Automate → Schedules → Overrides: list of all active overrides, and Create Override for a resource or a group

For configuring the override mechanics, continue to L2.

Related lessons

• L2: Force-on, force-off, expiry, reason (next)
• L4: Override expiry and conflicts
• M1.2 L4: Manual start/stop

Glossary terms touched

Override