Override Actions

Manually control hibernation operations outside of the regular schedule. Hibernator provides two complementary mechanisms — Override Action for persistent schedule bypass and Restart for one-shot re-execution.

No Force Actions

Hibernator does not have a force-hibernate or force-wakeup mechanism. Instead, use Override Action to persistently drive a plan toward a target phase, or Restart to re-trigger the last executor operation as a one-shot action.

Override Action

Override Action is a persistent manual phase override. While active, the controller ignores the configured schedule entirely and drives the plan toward the specified target phase (hibernate or wakeup). The plan stays locked at the target phase until the override is explicitly deactivated.

Activate Override

CLIkubectl

# Force the plan to hibernate immediately
kubectl hibernator override dev-offhours --to hibernate

# Force the plan to wake up immediately
kubectl hibernator override dev-offhours --to wakeup

# Force hibernate
kubectl annotate hibernateplan dev-offhours -n hibernator-system \
  hibernator.ardikabs.com/override-action=true \
  hibernator.ardikabs.com/override-phase-target=hibernate

# Force wakeup
kubectl annotate hibernateplan dev-offhours -n hibernator-system \
  hibernator.ardikabs.com/override-action=true \
  hibernator.ardikabs.com/override-phase-target=wakeup

Deactivate Override

CLIkubectl

kubectl hibernator override dev-offhours --disable

kubectl annotate hibernateplan dev-offhours -n hibernator-system \
  hibernator.ardikabs.com/override-action- \
  hibernator.ardikabs.com/override-phase-target-

After deactivation the controller resumes normal schedule evaluation immediately.

Override with Automatic Expiration

By default, overrides are persistent and remain active until explicitly disabled. However, you can set an automatic expiration time using the --until flag (CLI) or override-until annotation (kubectl). When the deadline is reached, the controller automatically deactivates the override and restores normal schedule control.

CLI (Natural Language)CLI (Seconds)kubectl (RFC3339)

# Override for 2 hours using relative time
kubectl hibernator override dev-offhours --to wakeup --until "in 2 hours"

# Override until tomorrow morning
kubectl hibernator override dev-offhours --to hibernate --until "tomorrow at 8am"

# Override until a specific date/time
kubectl hibernator override dev-offhours --to wakeup --until "2026-01-15 14:30"

# Override for exactly 7200 seconds (2 hours)
kubectl hibernator override dev-offhours --to wakeup --seconds 7200

# Set override with automatic expiration using RFC3339 UTC format
kubectl annotate hibernateplan dev-offhours -n hibernator-system \
  hibernator.ardikabs.com/override-action=true \
  hibernator.ardikabs.com/override-phase-target=wakeup \
  hibernator.ardikabs.com/override-until="2026-01-15T14:30:00Z"

Supported Time Formats:

Format Type	CLI Example	Annotation Value
Relative	in 30 minutes, in 2 hours, in 1 day	N/A
Tomorrow	tomorrow at 6am, tomorrow at 14:30	N/A
Next	next Monday, next week	N/A
Date	2026-01-15, Jan 15, 2026	N/A
Date+Time	2026-01-15 14:30, Jan 15, 2026 2:30pm	N/A
RFC3339	2026-01-15T14:30:00Z	2026-01-15T14:30:00Z

Timezone Handling

CLI natural language and date/time formats are interpreted in your local timezone and stored as UTC internally. The override-until annotation must always use RFC3339 format in UTC (e.g., 2026-01-15T14:30:00Z).

How It Works

1. The controller detects hibernator.ardikabs.com/override-action=true and reads the companion override-phase-target annotation.
2. If hibernator.ardikabs.com/override-until is set, the controller checks if the current time exceeds the deadline.
3. If expired: The override is automatically deactivated (annotations are removed) and normal schedule control resumes.
4. If not expired: The override remains active and schedule-driven transitions are suppressed.
5. Schedule-driven phase transitions are suppressed while the override is active.
6. The plan is driven toward the target phase via executor dispatch.
7. Once the target phase is reached, subsequent reconcile ticks become no-ops (the override remains active, but no work is dispatched).
8. Without an expiration, the annotations are persistent — the controller never removes them. The user must explicitly deactivate.

Persistent Override

Without --until, --seconds, or the override-until annotation, the override stays active indefinitely. If you forget to deactivate it, the plan will never follow its schedule again until the annotations are removed. Always set an expiration when possible, or remember to deactivate when done.

When to Use Override

• Emergency wakeup: Need resources running urgently outside of scheduled hours
• Planned maintenance: Force hibernation during an off-schedule maintenance window
• Testing: Drive the plan through a full hibernate/wakeup cycle without waiting for the schedule
• Incident response: Wake up resources and keep them running throughout an incident

---

Restart

Restart is a one-shot action that re-triggers the last executor operation as recorded in .status.currentOperation. The controller consumes the annotation atomically before re-execution — it cannot loop.

Trigger Restart

CLIkubectl

kubectl hibernator restart dev-offhours

kubectl annotate hibernateplan dev-offhours -n hibernator-system \
  hibernator.ardikabs.com/restart=true

How It Works

1. The controller detects hibernator.ardikabs.com/restart=true.
2. The annotation is consumed (deleted) in a single atomic patch before re-execution.
3. The controller reads .status.currentOperation to determine the operation:
   • If currentOperation=hibernate and the plan is in Hibernated phase → re-triggers the hibernation executor.
   • If currentOperation=wakeup and the plan is in Active phase (with restore data present) → re-triggers the wakeup executor.
4. Phase/operation mismatches are no-ops with a warning; the annotation is still consumed.

Requirements

• The plan must be in Active or Hibernated phase (stable resting phases).
• .status.currentOperation must be recorded — the plan must have completed at least one full hibernation cycle.
• For wakeup restarts, restore data must exist.

When to Use Restart

• Partial success: Re-apply a hibernation or wakeup that succeeded for some targets but not others
• Idempotency testing: Verify that an executor handles repeated invocations correctly
• Configuration change: Re-run after updating executor parameters on a target

Restart + Override

Restart works both standalone and alongside Override Action. While an override is active and the plan has reached the target phase, you can annotate restart=true to re-run the executor one more time.

---

Quick Comparison

Feature	Override Action	Restart	Retry
Behaviour	Persistent	One-shot	One-shot
When to use	Bypass schedule entirely	Re-run last operation	Recover from Error phase
Required phase	Active or Hibernated	Active or Hibernated	Error
Annotation consumed?	No (user removes)	Yes (atomic)	Yes
CLI command	kubectl hibernator override	kubectl hibernator restart	kubectl hibernator retry

Retry vs Restart

Retry is for plans stuck in the Error phase — it clears error state and re-attempts the failed operation. Restart is for plans already at a stable phase (Active or Hibernated) — it voluntarily re-triggers the last operation. Use the right tool for the situation.

Annotation Reference

Annotation	Value	Behaviour
hibernator.ardikabs.com/override-action	"true"	Enables persistent schedule override. Must be paired with override-phase-target.
hibernator.ardikabs.com/override-phase-target	hibernate or wakeup	Specifies the target phase for override.
hibernator.ardikabs.com/override-until	RFC3339 UTC (e.g., 2026-01-15T14:30:00Z)	Optional deadline for automatic override expiration. When current time exceeds this value, the controller automatically deactivates the override.
hibernator.ardikabs.com/restart	"true"	One-shot re-trigger of last executor operation. Consumed by controller.
hibernator.ardikabs.com/retry-now	"true"	One-shot retry for Error phase plans. Consumed by controller.