Managing active overrides

Outcome

By the end of this lesson, you will be able to list active overrides, cancel one early when the situation resolves, and read its end time correctly.

1. Concept

Every override currently running is on the Overrides tab of Automate → Schedules.

It answers three questions: what is overridden, when it ends, and whether you can end it now.

The Overrides tab

OVERRIDES                                         Status: All statuses
──────────────────────────────────────────────────────────────────────────────
NAME                STATUS   OVERRIDE TYPE  REASON                  START TIME    END TIME
──────────────────────────────────────────────────────────────────────────────
staging-eu-cluster  Active   Keep Running   Acme Corp demo Sat 2pm  3 hours ago   May 25, 08:00 Europe/London
dev-platform-aws    Active   Force Stop     Planned cluster         1 hour ago    May 22, 18:00 America/New_York
                                            migration (DEV-4521)
ml-experiments      Expired  Force Stop     DR drill, all-team      2 days ago    May 21, 09:00 Asia/Kolkata
──────────────────────────────────────────────────────────────────────────────

Each row shows:

• Name: the resource or group the override applies to (a group carries a Group tag and links to the group)
• Status: Active or Expired
• Override Type: Keep Running or Force Stop
• Reason: the documented reason
• Start Time: when the override was created, as relative time (“3 hours ago”)
• End Time: when it ends, as an exact date and time
• Actions: Cancel Override

There is no detail panel: everything about an override is on its row.

Reading the end time

The End Time column shows the exact moment the override ends, in the timezone of the schedule it is attached to, with the zone name printed beside it. If your team works in a different zone from the schedule, convert before you promise anyone a time.

Filtering and sorting

The Overrides tab supports filtering and sorting:

FILTERS                              SORT BY
─────────────────────────────────────────────────────
Search (target name or UID)           Start time (default: newest first)
Status (All / Active / Expired)       End time
Target (Resource / Group)
Type (Keep Running / Force Stop)

A common workflow: filter Status to “Active” + sort by End time, ascending → see the overrides that end soonest first, ordered by urgency.

Cancel an override early

When the situation that motivated an override is resolved before expiry, cancel:

1. Open the Overrides tab.
2. Find the override.
3. Click Cancel Override.
4. Confirmation dialog: "Cancel Override. This action cannot be undone."
   Type the target's name to confirm.
5. Confirm.
6. ZopNight ends the override and sends the opposite action right away
   (a cancelled force-on stops the resources; a cancelled force-off
   starts them). The schedule's crons then act normally.

There is no cancellation reason field: the cancel carries no text. ZopNight sends an override-cleared notification that names who cancelled it, and the Audit Log records the cancel. If the reason for ending early matters, put it in your ticket or team channel.

Why cancel early matters

If a force-on override is left running until expiry but the underlying need ended early, the resources stay on for the unneeded hours: burning cost the team thought they had saved. The cancel-early pattern recovers those hours.

SCENARIO:
  Force-on override set for 72 hours for a demo.
  Demo ends after 18 hours.

WITHOUT CANCEL:
  Override expires at 72 hours. Resources stay on for 54 unneeded hours.
  $1,200 in unnecessary cost.

WITH CANCEL:
  Override cancelled at 19 hours. ZopNight stops the resources right away
  (the opposite of force-on). $1,200 saved.

The team builds the habit: when the situation resolves, cancel the override. Don’t wait for expiry.

Expired overrides: the archive

Set the Status filter to “Expired” to see overrides that ran to their end time:

EXPIRED OVERRIDES (Status: Expired)
────────────────────────────────────────────────────────────
NAME                STATUS   OVERRIDE TYPE  REASON               END TIME
────────────────────────────────────────────────────────────
old-demo            Expired  Keep Running   Demo for Beta Corp   May 19, 08:00 Europe/London
maint-window-march  Expired  Force Stop     Cluster migration    May 13, 18:00 America/New_York
incident-may-12     Expired  Keep Running   Incident 2026-05-12  May 12, 23:00 Asia/Kolkata
────────────────────────────────────────────────────────────

The archive is useful for:

• Audit: “How many demo overrides did we do last quarter?”
• Pattern detection: “We’re applying force-off for migrations every Tuesday. Should that be a scheduled maintenance window instead?”
• Cost reconciliation: “What hours did our schedules NOT cover because of overrides last month?”

Expired overrides are not purged: they stay in the Expired list. A cancelled override is different: it disappears from the list entirely, so its only record is the cancel in the Audit Log.

What you cannot do

Three things deliberately not exposed:

1. Extend an override. To extend, cancel the current override and create a new one with the new expiry. This is intentional; extending past the original expiry should be a deliberate, re-documented decision.
2. Modify the reason after creation. The reason is the historical record. To “update” the reason, cancel and recreate.
3. Keep a cancelled override on the list. Cancel is the only way to end an active override early, and a cancelled override disappears from the Overrides tab. The Audit Log keeps the record of the cancel.

These restrictions keep the override history honest.

2. Demo

A typical Friday workflow on the Overrides tab:

T+0       Engineer opens Overrides tab on Friday afternoon.
T+5 sec   12 overrides visible. Search for the team's prefix → 4 overrides.

T+10 sec  Review each:
            Override 1: demo-weekend, expires Monday 8am. Still needed.
            Override 2: maint-window from yesterday. Already expired; it
                       shows because the Status filter is on "All".
            Override 3: incident-response, originally 24h, incident resolved.
            Override 4: dr-drill-prep, scheduled for next week, expires Monday.

T+30 sec  Engineer clicks Cancel Override on #3 (incident resolved).
T+45 sec  Types the target's name to confirm.
T+50 sec  Override #3 cancelled; ZopNight sends the opposite action.

T+1 min   Engineer closes the page, confident the overrides reflect reality.

The pattern: review weekly, cancel anything no longer needed. Five minutes per week, much better than discovering forgotten overrides during an audit.

3. Hands-on (6 min)

For your sandbox (with overrides from L2):

1. Open the Overrides tab.
2. Note the active count.
3. Pick one override and read its row: name, status, type, reason,
   start time, end time.
4. Check the End Time against the timezone printed beside it.
5. Note the override's name so you can find its cancel in the Audit Log.
6. Cancel one override:
   - Click Cancel Override
   - Type the target's name in the confirmation dialog
   - Confirm
7. Verify the override has disappeared from the list, and find the
   cancel in the Audit Log.
8. Verify the resource's schedule is no longer suspended (ZopNight sends
   the opposite of the override's action right away, then the schedule's
   crons act normally).

4. Knowledge check

Q1

A force-on override was set for a 72-hour demo. The demo ended after 18 hours. The most cost-aware action is:

A. Wait for expiry
B. Apply a new override
C. Modify the expiry to a shorter value
D. Cancel the override immediately

Q2

A team needs to “extend” an override past its original expiry. The right approach is:

A. Click Extend
B. Disable the whole schedule instead of extending
C. Cancel the current override, then create a new one
D. Modify the expiry

Q3

A team wants to review an override that expired four months ago. Where do they find it?

A. Nowhere: expired overrides are purged after a short window
B. In the AWS console, since AWS keeps the data rather than ZopNight
C. Nowhere: expired overrides can never be queried after expiry
D. On the Overrides tab, with the Status filter set to Expired

5. Apply

Override management:

• Automate → Schedules → Overrides: active list, expired archive, filter, cancel
• Resource detail → override details inline
• Group detail → override details inline
• Audit Log: full history of override events

For the rules that decide when ZopNight accepts or rejects an override, and what happens at creation and expiry, continue to L4.

Related lessons

• L4: Override expiry and conflicts (next)
• T4.M4.3: Audit logging

Glossary terms touched

Override