Freeze windows · ZopDev University

Outcome

By the end of this lesson, you will be able to implement schedule freeze windows for holidays and special events, choose the right granularity (org-wide / targeted / per-resource), and communicate freezes to the team to avoid surprise.


Prerequisites	M3.2.L1 - L3 · T1.M1.5 (override system)
Time	9 minutes

1. Concept

A freeze is a period when scheduled stops do not fire. In ZopNight it is a force-on override: it starts anything stopped straight away and keeps it up until the override expires.

You use one when:

WHEN TO FREEZE:

HOLIDAYS
  Christmas / New Year
  Thanksgiving / Easter
  National holidays per region
  Reason: engineers offline; can't respond to unexpected shutdowns

CONFERENCE WEEKS
  KubeCon, re:Invent, SaaStr, etc.
  Reason: demo environments need to stay available

MAJOR LAUNCHES
  Big product launches
  Reason: stability prioritized over cost savings

COMPLIANCE WINDOWS
  SOC 2 / ISO audit period
  Annual financial close
  Reason: auditor expects stable environment

MAINTENANCE WINDOWS
  Cloud provider maintenance
  Migration weekends
  Reason: don't compound disruption with scheduled stops

The freeze is a deliberate pause of normal scheduling discipline. Document the reason; expire it at the right time.

What a freeze does

DURING A FREEZE:
  ✓ No scheduled stops fire (no off-hours stops, no scale-down)
  ✓ Stopped targets start immediately and stay running
  ✓ Engineers don't return to unexpected shutdowns
  ✓ Cost is higher during the freeze (you pay for the freeze)

FREEZE DOES NOT:
  ✗ Affect resources it was not created on
    (an override covers one scheduled resource or one group;
     everything else follows its schedule normally)
  ✗ Change underlying schedules (just suspends firing)
  ✗ Affect manual actions (engineers can still stop/start manually)
  ✗ Block engineering changes (deployments still happen)

The freeze is scope-limited to ZopNight’s scheduled actions; everything else continues.

Configuring via ZopNight override system

ZopNight implements freezes via the override mechanism (covered in T1.M1.5):

OVERRIDE CONFIGURATION for a freeze (one per target):

  Action:       force_on
  Target:       one scheduled resource OR one resource group
                (a resource in a group is overridden at group level)
  Expires:      2027-01-02 00:00 UTC (auto-expiry)
  Reason:       "Holiday freeze: no scheduled stops"
  Created by:   recorded automatically

  Starts:       the moment you create it; there is no scheduled
                start, so create it on the first day of the freeze
  Approval:     no approval field; run sign-off in your own process

EFFECT while the override is active:
  The schedule's stop actions are ignored for that target
  Resources stay running
  Audit log records the override + reason
  Notification fires when the override is set, cleared or expires

POST-FREEZE (auto-expiry):
  Override expires
  Schedules resume firing
  No human action needed

Only resources and groups with a schedule attached can take an override. A whole-estate freeze is therefore one override per scheduled group (plus any scheduled resources outside groups).

The auto-expiry is critical: manual cleanup gets forgotten and freezes drift.

Example freeze patterns

CHRISTMAS / NEW YEAR FREEZE:
  Override starts: Dec 20 00:00 UTC
  Override ends:   Jan 2 00:00 UTC
  Duration: 13 days
  Target: every non-prod scheduled group (one override each)
  Cost: ~$6K extra (would have been off; full-cost during freeze)
  Justification: avoid Monday-back-from-holiday surprise outages

MAJOR PRODUCT LAUNCH FREEZE:
  Override starts: 1 week before launch (Mon)
  Override ends:   1 week after launch (Mon)
  Duration: 2 weeks
  Target: the groups holding production-critical systems + dependencies
  Justification: stability over savings during launch validation

CONFERENCE WEEK FREEZE (re:Invent):
  Override starts: Mon of conference
  Override ends:   Fri of conference week
  Target: demo environments + presenter dev envs
  Justification: demo continuity

ANNUAL FINANCIAL CLOSE:
  Override starts: Dec 28
  Override ends:   Jan 5
  Target: finance + billing systems
  Justification: no disruption during year-end reporting

QUARTERLY SOC 2 AUDIT WINDOW:
  Override starts: audit-start date
  Override ends:   audit-end date
  Target: in-scope resources (per audit boundary)
  Justification: auditor sees stable environment

Common patterns; each has a clear cost/benefit trade.

Freeze granularity: three levels

LEVEL 1: ORG-WIDE FREEZE
  Apply to: every scheduled resource group (one override each)
  Scope: everything
  Use when: holiday with all engineers offline
  Cost: highest (all schedulable resources stay running)
  Risk: lowest (nothing surprises)

LEVEL 2: TARGETED FREEZE
  Apply to: specific groups (e.g., the prod-critical group)
  Scope: business-critical only
  Use when: launch / compliance affecting specific scope
  Cost: medium (non-critical still cycles)
  Risk: medium (engineer might miss a critical resource)

LEVEL 3: PER-RESOURCE FREEZE
  Apply to: specific ungrouped resources (e.g., 5 instances)
  Scope: narrowest
  Use when: specific high-stakes systems need protection
  Cost: lowest (only the listed resources)
  Risk: highest tracking (easy to miss something)

Choose granularity matching the freeze reason. Holidays: org-wide. Launches: targeted. Specific systems: per-resource.

Annual freeze calendar

Most teams maintain a calendar of recurring freezes:

ANNUAL FREEZE CALENDAR (example):

  Dec 20 - Jan 2:   Christmas / New Year (org-wide non-prod)
  Mid-March:        Q1 close (finance systems only)
  Mid-June:         Q2 close
  Mid-Sept:         Q3 close
  Mid-Dec:          Q4/annual close (extended through new year)
  Nov 25 - Dec 1:   Thanksgiving + Black Friday (e-commerce only)
  Late June:        Eid (regional, MENA team)
  Various:          Per-team Diwali / Lunar New Year / etc.

CONFERENCES (per-team):
  Mar 4-7:    Platform lead attends KubeCon
  Jun 12-14:  Whole team at Demo Day
  Dec 1-5:    re:Invent (cloud team)

LAUNCHES (planned 2026):
  Q1 launch:  Feb 15-22 (1 week before/after)
  Q3 launch:  Aug 10-17

REVIEW: quarterly
OWNER: Platform team lead

Publish the calendar; reference it in onboarding. Engineers know when freezes happen.

Communication: never silent

FREEZE COMMUNICATION CHECKLIST:

PRE-FREEZE (1-2 weeks before):
  □ Team Slack: "Holiday freeze Dec 20 - Jan 2; non-prod stays up"
  □ Wiki page updated with current freezes
  □ On-call runbook updated
  □ Cost impact estimated and shared

DURING FREEZE:
  □ Daily cost monitoring (catch unintended spikes)
  □ Override visible in ZopNight UI
  □ Engineers can see freeze status when they log in

POST-FREEZE:
  □ Verify normal schedules resumed
  □ Document any incidents that occurred
  □ Cost reconciliation (freeze cost vs estimate)
  □ Lessons learned for next freeze

The communication is what makes freezes acceptable to leadership: they understand the cost trade.

Cost of a freeze

EXAMPLE COST IMPACT (Christmas freeze, 13 days, org-wide non-prod):

NORMAL non-prod cost (with schedules): $14K/mo = $467/day
DURING FREEZE (no scheduled stops): $467 × (24/12) = ~$933/day
                                    (~2x because schedules normally
                                     halve the daily cost)
FREEZE DURATION: 13 days
EXTRA COST: ($933 - $467) × 13 = $6,058

VALUE: avoid 1-2 unintended outages during the holidays
       Each outage: hours of engineer time to investigate + recover
       Plus: customer-trust impact

DECISION: $6K is worth it for the freeze; engineers offline
          rendered the savings moot anyway (engineers would have
          force-started everything Monday at higher cost)

Freezes are deliberate cost trades. Document; review post-freeze for ROI.

Common pitfalls

PITFALL                              MITIGATION
──────────────────────────────────────────────────────────────────
Override left in place after        Always set auto-expiry datetime
event (cost balloons)               Calendar review post-event

Engineer adds resource during        Document: "new resources during
freeze; assumes it's also frozen     freeze still follow normal schedule"
                                    Or: if scheduled and ungrouped, give
                                        it its own override

Overlapping freezes on the same     ZopNight allows one active
group                               override per resource or group
                                    and rejects a second
                                    (already_overridden); extend or
                                    replace the existing override

Team forgets to communicate          Pre-freeze checklist
freeze; team confused about           Slack reminder 1 week + day-of
unexpected costs

Override granularity wrong          Test with small group first
(too narrow; missed resources)       Audit affected vs unaffected

Costs balloon during freeze         Daily cost monitoring during
without notice                       Alert if cost >X% of normal

Most pitfalls are process gaps. The annual freeze calendar + communication checklist prevent most.

2. Demo

An illustrative Christmas freeze rollout (example plan and figures):

TEAM: 200-engineer SaaS, mostly US-based

PLANNING (Dec 5: 2 weeks ahead):

  Identify scope:
    Org-wide non-prod (engineers offline; full freeze)
    Production excluded (always-on anyway)

  Estimate cost:
    Normal non-prod (with schedules): $14K/mo
    During freeze (no schedules): $14K × 2 ≈ $28K/mo run rate
    Freeze duration: 13 days
    Extra cost: ($28K - $14K) × (13/30) = $6,067

  Get sign-off:
    Cost owner (CFO ops): approved
    Platform lead: approved
    Engineering VPs: notified

COMMUNICATION:
  Dec 5:   #eng-platform Slack post
           "Holiday freeze planned Dec 20 - Jan 2:
            * Non-prod stays on (no scheduled stops)
            * Estimated extra cost: $6K (reviewed + approved)
            * New resources during freeze: follow normal schedule
            * Production: unchanged
            * Engineers: don't expect anything unusual on return"
  Dec 12:  Reminder + wiki update
  Dec 18:  Final reminder; on-call runbook updated

EXECUTION (Dec 20):
  Dec 20 00:00 UTC: Overrides created, one per non-prod group
                   (prod has no schedule, so it needs none)
                   Action: force_on
                   Expires: Jan 2 2027 00:00 UTC
                   Reason: "Holiday freeze 2026"

  Dec 20 00:01:    Override notifications reach the #eng-platform
                   Slack channel (one per group)

MONITORING (mid-freeze):
  Dec 23: cost check; tracking $935/day (vs $467/day normal)
          Within projection.
  Dec 27: cost check; same.
  Dec 31: cost check; same.

EXPIRY (Jan 2):
  Jan 2 00:00 UTC: Override expires automatically
                   On its next evaluation pass, ZopNight sends a
                   stop for each resource the override held on
                   (read-only accounts are skipped)
                   Schedules resume from the next start cron
                   No human action needed.

POST-FREEZE REVIEW (Jan 5):
  Cost reconciliation:
    Estimated extra: $6,067
    Actual extra:    $5,940 (matched within 2%)

  Incidents during freeze: 0
  Engineers surprised on return: 0

  ROI: $5,940 cost; avoided likely 1-2 unintended outages;
       team return-from-holiday clean.

  Calendar updated for 2027 Christmas freeze (same pattern).

The pattern is repeatable annually. Set it once, refine each year.

3. Hands-on (5 min)

Build your freeze calendar:

□ STEP 1: List upcoming freezes (next 12 months)
  Christmas/New Year:    __________ - __________
  Major launch?           __________ - __________
  Conference?             __________ - __________
  Compliance audit?       __________ - __________
  Annual close?           __________ - __________
  Regional holidays?      __________

□ STEP 2: For each, decide granularity
  □ Org-wide
  □ Targeted (which groups)
  □ Per-resource

□ STEP 3: Estimate cost
  Freeze 1: __________   Duration: ___ days   Extra cost: $_____
  Freeze 2: __________   Duration: ___ days   Extra cost: $_____

□ STEP 4: Plan communication
  Pre-freeze: __________ (Slack channel + wiki page)
  During:     __________ (cost monitoring + status visibility)
  Post:       __________ (review + lessons)

□ STEP 5: Calendar reminder
  Set calendar reminders 2 weeks before each freeze
  Owner: __________

A 30-minute planning session sets up the year of freezes. Saves hours of mid-event scrambling.

4. Knowledge check

Q1

A freeze window suspends:

A. Scheduled actions during the window
B. New resources from being provisioned
C. Notifications for the duration
D. Everything in ZopNight

Show answer

Correct: A. Existing state is preserved and only scheduled actions are suspended. An override covers only the resource or group it was created on, so anything else keeps its schedule, and other operations (manual stops, deploys) continue.

Q2

Freeze override expiry:

A. Manual extend required
B. Automatic at the configured expiry datetime
C. At the end of the calendar month always
D. Never expires

Show answer

Correct: B. Set it explicitly when creating the override. Auto-expiry prevents “freeze drift”, where a forgotten override keeps cost high indefinitely; manual extensions get forgotten.

Q3

A Christmas freeze for production-critical systems:

A. Targeted: freeze on production-critical groups specifically
B. Always org-wide
C. Per-account, with exactly one freeze window per account
D. Per-resource always

Show answer

Correct: A. Other non-critical groups can continue normal schedules (still saving cost). Granular freezes minimize cost while protecting what needs protection. Choose granularity to match the freeze reason. Granular freeze. Match scope to reason.

5. Apply

Annual freeze calendar. Use ZopNight overrides (force_on, one per scheduled group, created on the first day, with an expiry). Communicate pre/during/post. Document cost trade-offs.

For your team: build a 12-month freeze calendar this quarter. Plan ahead; communicate clearly.

Glossary terms touched

Override

Outcome

1. Concept

What a freeze does

Configuring via ZopNight override system

Example freeze patterns

Freeze granularity: three levels

Annual freeze calendar

Communication: never silent

Cost of a freeze

Common pitfalls

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.