create_power_schedule
Create a power schedule on an Ankra-provisioned self-managed cluster: a scheduled stop or start that fires once at run_at (schedule_kind 'once') or repeatedly per a standard 5-field cron_expression evaluated in an IANA timezone (schedule_kind 'cron'), executed within a minute of falling due. By default (stop_mode 'delete_resources') a fired stop behaves exactly like stop_cluster - it TERMINATES every VM of the cluster at the provider and preserves only the configuration for a later start (except on Scaleway, where servers are powered off and kept, with retained storage, gateway, and flexible IP still billable) - so state the schedule's action, stop mode, and timing to the user before creating it. stop_mode 'scale_to_zero' instead DELETES the worker servers at the provider (workloads stop) and keeps the control plane (with etcd), networks, SSH keys, and cloud volumes, which keep billing; the matching start creates new workers with the previous configuration. Anything on a worker's own disk - local-path, hostPath or other node-local persistent volumes, emptyDir - is lost at every stop, so tell the user this before creating a scale_to_zero schedule, and the result's node_local_storage names the claims at risk when the cluster inventory shows any (or says it could not tell). An enabled scale_to_zero stop on a cluster whose inventory shows such claims is refused unless accept_node_local_data_loss is true: the refusal names the claims, so show them to the user, ask whether they accept losing that data at every stop, and call create_power_schedule again with accept_node_local_data_loss true only after the user has explicitly agreed. To stop a cluster at night or at weekends to save cost, use propose_off_hours_schedule instead: it files the off-hours decision with its gate, receipt and measurement. Use create_power_schedule for one-off stops and starts and for schedules the user asks for that are not the off-hours saving. A stop fired while the cluster is already stopped is skipped, a start fires on a stopped cluster (full re-provision) or on a running cluster whose workers a scale-to-zero stop removed (worker restore), and a busy cluster defers the action (retried every 5 minutes for up to 24 hours). At most 20 schedules per cluster. The schedule itself is reversible: delete_power_schedule removes it before it fires.
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 | No | Whether the schedule is armed. Defaults to true; pass false to create it paused. | |
| timezone | No | IANA timezone the cron expression is evaluated in, e.g. 'Europe/Stockholm'. Defaults to UTC. | |
| 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. | |
| 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. |