Schedules

Set the snapshot schedule

How long these are kept is your plan’s retention, not a field here — read it at GET /retention, which is what tells you how many of the snapshots this schedule takes will still be there next month.

The PUT replaces the whole window: hour and minute default to 0 and tz to UTC, so send all three again when only toggling enabled. A computer being copied or moved answers 409; send it again once that finishes.

A computer that is not running is captured only if its disk has changed since its last automatic snapshot; a stopped or suspended computer left unused takes no new automatic snapshot, so an old newest snapshot on one is not a missed window.

AUTOMATIC CAPTURES COUNT AGAINST YOUR SNAPSHOT STORAGE ALLOWANCE, and can be skipped when it is full. Their bytes count toward the same allowance a manual capture does, so they can bring an account to the point where a manual capture answers 402; and a scheduled capture skipped for storage is not taken. Nothing is deleted to make room for it. It is retried through the rest of that day and is taken once there is room — retention ageing out an older automatic snapshot, or you deleting one. Room is measured across every computer on the account, normally once an hour, and each host is sent its share. A measurement is sent only when every host answers it, and until a complete one reaches a host, that host keeps the share it was last sent. So a skipped capture usually waits up to an hour after room appears, longer while any host cannot be measured, and one can still land shortly after the allowance fills. Each plan’s allowance is sized to hold the history its retention keeps, so a schedule meets it only when manual snapshots or unusually busy disks have used that room.

A NEW ACCOUNT OR A NEWLY PLACED COMPUTER CAN ALSO BE SKIPPED UNTIL THE NEXT COMPLETE MEASUREMENT. Each host’s share of the room left in the allowance is in proportion to the account’s computers on it. Until a complete measurement reaches the host, a new account has no share anywhere, and a computer created on or moved to a host where the account had no computers has none there, so its scheduled capture is skipped even with nothing stored. That is normally within the hour, but a host that cannot be measured, or a share that cannot be delivered, can stretch it to hours or days. A skipped capture is retried through the rest of that day like any other, so a longer wait can cost that day’s capture.

One automatic capture a day, and an edit does not add another. Changing the time or tz after today’s capture has been taken moves the window from tomorrow on; it does not open a second one today, and neither does removing the schedule and setting it again in the same tz.

Requires the member role or higher.

put/computers/{id}/schedule

Request

  • Base URL: https://app.mandala.computer/api/v1
  • URL: https://app.mandala.computer/api/v1/computers/{id}/schedule
  • Auth: HTTP bearer

Path parameters

idstring required

The computer id.

Request body

enabledboolean required
hourinteger

0–23, in tz. 0 when left out.

minuteinteger

0–59. 0 when left out.

tzstring

IANA zone name, e.g. Europe/London. Defaults to UTC. A name the host’s zone database does not know is a 400.

Response

The schedule as stored.

enabledboolean required

Whether a capture is taken in this window. A computer that is not running is captured only if its disk has changed since its last automatic snapshot; a stopped or suspended computer left unused takes no new automatic snapshot.

hourinteger required

0–23, in tz.

minuteinteger required

0–59.

tzstring required

IANA zone name. UTC when unset.

Changes

No recorded changes to this operation across all 1 revision of this API.