Max override duration: the per-resource cap

Outcome

By the end of this lesson, you will be able to configure the per-resource Max Override Duration cap and explain why it prevents the most common operational hazard.

1. Concept

Max Override Duration is a ceiling, in minutes, on how long any one override may run. You set it on a single resource or on a group (max_override_duration_minutes).

There is no organisation-wide version of this and no default value. The number lives on the thing itself. Set it to 0 and overrides are not allowed there at all. Any number above 0 is the longest an override may last before it has to expire.

It exists to stop one specific thing happening. Somebody forces a resource on “just for this weekend” and forgets. That override outlives their notice period, a reorganisation, three quarterly reviews and a considerable bill before anybody notices it is still there.

Because the ceiling sits on each resource, you can be strict where it matters, or forbid overrides entirely, and generous where a long override is a perfectly normal thing to want.

Choosing a cap per resource

TYPICAL OVERRIDE NEEDS                       TYPICAL DURATION
─────────────────────────────────────────────────────────────
Customer demo                                 2-3 days
Maintenance window                            6-12 hours
Incident response                              12-48 hours
DR drill                                       1-2 days
Off-hours work session                         12-24 hours
Holiday weekend coverage                       3-5 days
End-of-quarter business review                 4-5 days

Most legitimate overrides finish inside about 5 days, so a cap in the ~5-to-7-day range (7,200 to 10,080 minutes) on a normal resource gives headroom while still catching the runaway. Anything structurally longer is a schedule edit, not an override:

• “Our team works Sundays in May” → edit the schedule for that period
• “Production is non-24/7 in this region” → edit the schedule permanently
• “Our DR site needs to stay on for a month” → edit or new schedule for that resource set

What happens when the cap is hit

USER SETS OVERRIDE on a resource whose max_override_duration_minutes
is 10,080 (7 days), with an expiry 30 days out.

ZopNight validation:
  "Override exceeds this resource's max duration (7 days). Reduce the
   expiry, or edit the schedule for a permanent change."

Reject. The user shortens the override, OR edits the schedule instead.
If the resource's cap is 0, the override is refused outright: overrides
are disabled on that resource.

The cap is set on the resource or resource group (admin action), and every override action is captured in the audit log.

Setting the cap where it matters

Because the cap is per-resource and per-group, you tune it to the resource:

RESOURCE: dr-cluster-eu
max_override_duration_minutes: 129,600 (90 days): extended for quarterly DR drills
Set by:   security-admin@org.com

RESOURCE: prod-payments-db
max_override_duration_minutes: 0: overrides disabled; never force this on/off manually

Setting the field is an admin action, and every override create/clear/expire is captured in the audit log.

Why this matters for compliance

Several compliance frameworks (SOC 2, ISO 27001) ask about “guardrails against indefinite policy bypasses.” The per-resource Max Override Duration is a defensible answer:

• The cap is configurable per resource and per group
• Sensitive resources can set it to 0, disabling overrides entirely
• Every override action is captured in the audit log
• Override history is retained in the audit log

A SOC 2 auditor can verify these properties from the audit log plus the per-resource setting. The control is testable.

What this cap does NOT do

Three deliberate limitations:

1. Does not limit the number of overrides. A team can have many active overrides simultaneously, each within its resource’s duration cap. The cap is per-override duration, not total override count.
2. Does not auto-cancel overrides. Overrides expire at their set expiry time. The cap rejects creation of an over-long override; it does not retroactively shorten existing ones.
3. Does not require a reason. The override reason is optional (the backend does not store a reason field), so it cannot be relied on as a machine-enforced control. Use it for human context, not validation.

The cap is a guardrail, not surveillance. It catches the one mistake people actually make, an override left on for ever, without micromanaging legitimate ones.

Choosing a cap per resource class

RESOURCE CLASS                            SUGGESTED max_override_duration
─────────────────────────────────────────────────────────────────────
Dev / staging compute                      ~7 days (10,080 min)
Standard production                        ~3-5 days (4,320-7,200 min)
Sensitive / stateful (payments DB, etc.)   0 (overrides disabled)
DR / drill resources                       longer, documented

Tightening a resource’s cap reduces its risk window but adds friction; setting 0 forbids overrides on resources that should only ever follow their schedule.

2. Demo

A team setting up the policy on a new ZopNight deployment:

DAY 1, T+0       Admin reviews override caps per resource / resource group.

T+1 min          Sets a ~7-day cap (10,080 min) on standard dev/staging groups.
T+2 min          Sets 0 on prod-payments-db: overrides disabled entirely there.
T+3 min          Sets 90 days (129,600 min) on dr-cluster-eu for quarterly drills.

T+5 min          Done. Each resource/group now carries its own
                  max_override_duration_minutes; there is no org-wide value.

DAY 30+   A 14-day override attempted on a dev group (7-day cap):
                Validation rejects: "Exceeds this resource's max (7 days).
                Shorten the override or edit the schedule."
                Team uses a 7-day expiry instead.
          A force-on attempted on prod-payments-db (cap = 0):
                Refused outright: overrides are disabled on that resource.

NO incidents of forgotten runaway overrides recorded over the first year.

A few minutes of per-resource setup. Zero forgotten-override incidents going forward.

3. Hands-on (5 min)

If you have admin access:

1. Pick a resource or resource group.
2. Find its Max Override Duration (max_override_duration_minutes).
3. Note the current value (remember: 0 = overrides disabled here).
4. Consider: does it match this resource's needs?
   - Are most overrides on it shorter than the cap?
   - Should sensitive resources be set to 0 (no overrides)?
   - Do any resources (DR, drills) need a longer cap?
5. Set the value per resource / group as needed.
6. Verify by attempting an over-long override in the create dialog
   (validation rejects values past that resource's cap).

For non-admin users: review the caps (read-only access) and use
them to inform your override decisions.

4. Knowledge check

Q1

A team needs to keep a non-prod environment running for a 2-week sprint. The resource’s max override duration is 7 days. The right approach:

A. Set two consecutive 7-day overrides
B. The 2-week sprint is too long for an override
C. Raise the resource’s max-duration cap first
D. Manually start resources every day

Q2

A user sets an override with 5-day expiry. The resource’s max override duration is 7 days. What happens:

A. Rejected
B. Warns the user
C. Capped automatically at the configured limit
D. Accepted: 5 days is within the 7-day cap

Q3

A SOC 2 auditor asks: “How do you prevent indefinite policy bypasses?” The defensible response includes:

A. The per-resource Max Override Duration cap (settable per resource and group, with 0 disabling overrides entirely on a resource), the required expiry on every override, and the audit log of all override events
B. “We trust our engineers”
C. “Overrides cannot exist”
D. “We don’t use overrides at all”, which is easy enough to say and impossible to evidence, since the absence of a record is not the same thing as a record showing nothing happened at all

5. Apply

Max Override Duration is in:

• The per-resource / per-group setting (max_override_duration_minutes on the resource or resource group; 0 disables overrides there)
• Audit Log: every override create / clear / expire event
• Override create dialog: validation enforces the cap

The broader access model, who can change policy and who can set overrides, is covered later in the course.

Module quiz

You have now completed all four lessons of M1.5. The module quiz (10 questions, 80% pass) is on the Operator certification page.

Related lessons

• M1.6: History, notifications, audit (next module)
• T3.M3.1: RBAC

Glossary terms touched

Max override duration · Per-resource exception · Indefinite-override hazard · Policy guardrail