update_power_schedule
Replace a power schedule's action, timing, and enabled flag, and re-arm its next run. This is a FULL REPLACE, not a patch: restate every field of the schedule as it should be afterwards - enabled must always be passed (an omitted enabled is refused rather than silently re-enabling a paused schedule), and a 'cron' schedule must restate its timezone (an omitted timezone is refused rather than silently shifting the fire hour to UTC). Call list_power_schedules first for the schedule_id and the current values. Passing enabled false pauses the schedule without losing its configuration; true re-arms it for its next occurrence. The same VM-termination caution and stop_mode semantics as create_power_schedule apply to stop schedules ('delete_resources' terminates every VM; 'scale_to_zero' deletes the worker servers, losing data on their own disks, and keeps the control plane running). A 'stop' schedule must also restate its stop_mode (an omitted stop_mode is refused rather than silently reverting a scale-to-zero schedule to the destructive default). An enabled scale_to_zero stop on a cluster whose inventory shows claims on a worker's own disk is refused unless accept_node_local_data_loss is true, which may only be set after the user has explicitly agreed to lose that data at every stop, exactly as for create_power_schedule. Do not use it to turn a schedule into an off-hours saving schedule; propose_off_hours_schedule files that decision.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What the schedule does when it fires. | |
| run_at | No | RFC 3339 timestamp of the single fire, e.g. '2026-01-02T19:00:00Z'. Required for schedule_kind 'once'; must be in the future. | |
| enabled | Yes | Whether the schedule is armed. Must always be passed on update: false pauses the schedule, true (re-)arms it. | |
| timezone | No | IANA timezone the cron expression is evaluated in, e.g. 'Europe/Stockholm'. Must be restated for 'cron' schedules. | |
| stop_mode | No | How a stop fires: 'delete_resources' (default) is the full stop_cluster teardown that terminates every VM; 'scale_to_zero' deletes the worker servers (data on their own disks is lost at every stop) and keeps the control plane, networks, SSH keys and cloud volumes; 'pause' powers every server off and keeps it with its disks (etcd and local data survive) - k3s clusters on Hetzner, UpCloud and DigitalOcean only, and what a stop always does on AWS and Scaleway. A pause saves no compute cost on Hetzner, DigitalOcean or UpCloud (Developer and General Purpose plans): they bill a powered-off server at its full price, so say so and offer scale_to_zero or delete_resources when the user wants to save. On AWS and Scaleway a powered-off server stops billing compute; its disks and IPs keep billing. Only meaningful with action 'stop'. | |
| cluster_id | No | UUID of the target cluster. Optional when a cluster is selected. | |
| schedule_id | Yes | UUID of the schedule to replace, from list_power_schedules. | |
| cluster_name | No | Exact name of the target cluster. Optional when a cluster is selected. | |
| schedule_kind | Yes | 'once' fires a single time at run_at; 'cron' fires repeatedly per cron_expression. | |
| preserve_state | No | For a 'stop' schedule with stop_mode 'delete_resources' on a provider whose stop deletes the VMs: capture the cluster's state (an encrypted etcd snapshot) before the teardown, and restore it on the next start. When the capture cannot run, the stop is refused and nothing is torn down; the failure says to set preserve_state false to allow a stop without saving state. Defaults to false on create; on update an omitted value keeps the schedule's current setting. Ignored for other schedules. | |
| cron_expression | No | Standard 5-field cron expression, e.g. '0 19 * * 1-5'. Required for schedule_kind 'cron'. Must not embed a timezone; use the timezone parameter. | |
| accept_node_local_data_loss | No | The user's explicit consent to losing the data on the worker disks at every stop of an enabled scale_to_zero stop schedule. On a cluster whose inventory shows persistent volume claims on a worker's own disk, such a schedule is refused without it and the refusal names the claims. Set it to true ONLY after you have shown the user those claims and the user has explicitly agreed to lose that data - never on your own judgement, never pre-emptively, and not because the user asked for the schedule. Ignored for every other schedule; defaults to false. |