Override expiry and conflicts

Outcome

By the end of this lesson, you will be able to predict whether ZopNight accepts or rejects an override and explain what happens to the resource when the override is created and when it expires.

1. Concept

An override has very few rules, and each one exists to stop a resource ending up in a state nobody can explain. There are five to know.

Rule 1: expiry is mandatory

Every override needs an Expires At time, and that time must be in the future. Leave it out and the create is rejected; set it in the past and the create is rejected. The time is read in the timezone of the schedule attached to the resource or group, which the create form shows next to the picker.

There is no upper limit on how far out the expiry can be. ZopNight checks only that it is in the future. The judgement call is yours: anything longer than a few days is usually a schedule edit, not an override (L1).

Mandatory expiry is the guardrail against the classic hazard: someone forces a resource on “just for this weekend” and forgets. With no expiry field, that override could outlive the person who set it. With one, it always ends.

Rule 2: one active override per resource or group

A resource or group can have one active override at a time. A second one is rejected with a 409 Conflict: “an active override already exists for this resource” (or “for this resource group”).

prod-api-1    force_on, expires Fri 18:00     ACTIVE
prod-api-1    force_off, expires Sat 09:00    REJECTED (409)

The create form’s picker shows the target as unavailable (“Already has an active override”) before you even submit. To change an active override, cancel it (L3) and create the new one.

Two related rules about the target:

• A resource that belongs to a resource group cannot get its own override. Override the group instead; the picker says “override the group instead”.
• A group override is stored as one override per member, all with the same action, reason and expiry. A group with no members is rejected.

Rule 3: an override acts when created and reverses at expiry

An override is not a flag that waits for the next cron. When you create it, ZopNight evaluates it straight away:

• Force-on starts the resource now (if it is stopped) and suppresses the schedule’s stop crons.
• Force-off stops the resource now (if it is running) and suppresses the schedule’s start crons.

When the expiry time passes, ZopNight sends the opposite action: an expired force-on stops the resource, and an expired force-off starts it. It does this whatever the schedule says at that moment. The schedule’s next cron then takes over again.

State history records both ends. The create shows a row with source override, and the expiry shows a row with source override_expired.

TUE 09:00   Force-off created on dev-db-2, expires Wed 17:00
            → dev-db-2 stopped now            (source: override)
TUE-WED     Schedule start crons are skipped
WED 17:00   Override expires
            → dev-db-2 started                (source: override_expired)
WED 19:00   Schedule stop cron fires as normal

Because expiry sends the opposite action unconditionally, pick an expiry that lands where you want the resource to end up. In the example above, an expiry of Wed 19:00 would have started the database for no reason at the moment the schedule wanted it off.

Rule 4: overrides apply only to scheduled resources

An override is an exception to a schedule. If the resource or group has no schedule attached, there is nothing to make an exception to, and the create is rejected: “cannot create override: resource has no schedule attached”. The override picker lists only scheduled resources and groups for this reason.

If you need a one-off change on an unscheduled resource, use a manual start or stop instead (M1.2).

One more target check: resources on a read-only cloud account cannot be overridden, because ZopNight cannot act on them.

Rule 5: the reason is optional but stored

The Reason field is not required and is not validated. Whatever you type is saved with the override and shown in the Reason column of the Overrides list.

Write one anyway. “Customer demo for Acme, ticket SALES-512” tells the next person whether the override can be cancelled. An empty reason tells them nothing. Do not build a compliance process that assumes a reason is always present, because ZopNight does not enforce one.

Accept or reject: the full check

CREATE OVERRIDE
  Expires At missing or in the past?           → rejected
  Account read-only?                           → rejected
  Resource is in a group?                      → rejected (override the group)
  Group has no members?                        → rejected
  No schedule attached?                        → rejected
  Already has an active override?              → rejected (409)
  Otherwise                                    → accepted, acts now

2. Demo

An on-call engineer handles a Thursday night incident on a scheduled staging stack:

THU 20:10   staging-api is stopped by its 20:00 schedule. QA needs it
            for an incident repro.
            Creates force-on on staging-api, expires Fri 02:00,
            reason "INC-881 repro".
            → Rejected: staging-api is in the group "staging-stack".
            Retargets the group "staging-stack" instead.
            → Accepted. All three members start within the minute.

THU 20:25   A teammate tries a force-on on "staging-stack" until Sat.
            → Rejected (409): an active override already exists.
            The picker had already shown the group as unavailable.

THU 23:40   Repro done early. The engineer cancels the override (L3).
            → All three members stop right away.

FRI 09:00   History for staging-api shows: started (override),
            stopped (override_deleted), then the normal schedule rows.

Every step is visible afterwards, and nothing ran past its window.

3. Hands-on (5 min)

In a non-production org:

1. Open the Overrides tab and start a new override.
2. In the target picker, find a resource marked unavailable.
   Read the reason it gives (in a group, already overridden,
   read-only, or no schedule).
3. Pick an eligible scheduled resource. Choose Force OFF.
4. Leave Reason empty for now and set Expires At about
   30 minutes out. Note the timezone shown next to it.
5. Create it. Confirm the resource stops within a minute
   and the Overrides list shows it as active.
6. Try to create a second override on the same resource.
   Note that the picker blocks it.
7. Wait for expiry (or cancel early). Open the resource's
   history and find the override_expired (or
   override_deleted) row that started it again.

4. Knowledge check

Q1

A team sets a force-on on a scheduled VM that expires in 90 days. What does ZopNight do?

A. Rejects it, because overrides are capped at 7 days
B. Accepts it, since an expiry only has to be in the future
C. Accepts it but silently shortens it to 30 days
D. Asks an admin to approve the long duration

Q2

A force-off on a database expires at Wed 17:00. Its schedule keeps it running 08:00-19:00. What happens at 17:00?

A. Nothing until the next schedule cron fires at 19:00
B. The database stays off until someone starts it by hand
C. ZopNight starts the database, the opposite of force-off
D. The override renews itself until the schedule window ends

Q3

You try to force-on a resource with no schedule attached. What happens?

A. The create is rejected, as there is no schedule to override
B. The override is saved and waits until a schedule is attached
C. ZopNight attaches a default always-on schedule automatically
D. The resource starts and stays on with no expiry at all

5. Apply

Override rules show up in:

• Automate → Schedules → Overrides: the create form (required Expires At, optional Reason, the target picker with unavailable targets explained) and the active list with its Reason column
• History: override, override_expired and override_deleted rows for each affected resource
• Audit Log: who created and cancelled each override

The broader access model, who can create overrides and on which resources, is covered later in the course.

Module quiz

You have now completed all four lessons of M1.5. Take the M1.5 module quiz: 10 questions, 80% to pass.

Related lessons

• M1.6: History, notifications, audit (next module)
• T4.M4.1: RBAC

Glossary terms touched

Override · Audit log