# Overrides

> Force a resource ON or OFF for a window, ignoring its schedule.

Source: https://zop.dev/docs/zopnight/concepts/overrides

---

An override is a time-bounded exception to a schedule. Use it when you need a resource up (or down) for a specific window and don't want the cron to fight you.

![Overrides table listing resource and group overrides with status, override type (Force Stop), reason, and start and end times](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/17e2715d-a757-4348-84df-6edfedc9f7f7-overrides.png)

*The Overrides page; each active or expired override with its type, reason, and window.*

## When to use an override

| Situation | What to do |
|---|---|
| Demo at 8pm tonight; dev cluster normally sleeps at 7pm | Force ON until 10pm |
| Code freeze for the next 48 hours; nothing should start | Force OFF on the group for 48 hours |
| Investigating an incident; stop the autoscaler resizing things underneath you | Force ON on the affected resources until resolved |
| Release tonight; staging should stay up regardless of schedule | Force ON on the staging group |

If the change is permanent, **edit the schedule** instead. Overrides are for windows, not for new policy.

## Create an override

**Pick the target**

  Either a single resource (from the resource detail drawer) or a resource group (from the group detail page).

**Pick a direction**

  **Force ON** prevents any scheduled stop from firing. **Force OFF** prevents any scheduled start from firing. ZopNight does not start a stopped resource just because you set Force ON; it only blocks the schedule from stopping it.

**Set the expiry**

  Choose a date/time and timezone. The override clears itself when the expiry passes; you don't need to remember to remove it.

**Add a reason**

  Required. Other admins seeing this override later need to know why it exists. ZopNight rejects overrides without a reason.

**Warning**

There's a **maximum override duration policy** on every org. Indefinite overrides defeat the purpose of scheduling; they're the most common reason savings quietly disappear. Override duration caps are configurable per org by an admin.

## Active overrides

The **Overrides** page lists every active override across the org with:

- Target (resource or group)
- Direction (Force ON / Force OFF)
- Time remaining (e.g. "expires in 5h 23m")
- Reason
- Who set it and when

Click any row to cancel the override early. Cancelling is immediate; the next scheduled cron fire will run normally.

## How overrides interact with schedules

Overrides take precedence over schedules but **do not start or stop resources on their own**. Think of an override as a "do not touch" sign that prevents the schedule from acting.

| Current state | Override | Scheduled action | Result |
|---|---|---|---|
| Running | Force ON | Stop | Stop suppressed. Resource stays running. |
| Stopped | Force ON | Start | Start runs normally. Override has no effect. |
| Running | Force OFF | Stop | Stop runs normally. Override has no effect. |
| Stopped | Force OFF | Start | Start suppressed. Resource stays stopped. |

If you want to actually start or stop a resource right now and ignore the schedule, use **manual start/stop** from the resource row menu; see [Resources](https://zop.dev/docs/zopnight/concepts/resources).

## Notifications

ZopNight notifies the attached channel when an override is:

- Set
- Cleared manually
- Expired automatically

This is opt-in per channel. By default the **Slack/Teams/GChat** channel attached to the resource or group gets the notification.

## Audit trail

Every override action (create, manual cancel, automatic expiry) is in the audit log with the actor, timestamp, and reason. Use the audit log when you're investigating "who turned off prod last weekend."