Schedules

Read snapshot retention

How long automatic snapshots are kept. Your plan decides this and there is no write here — which is the answer to the sentence on PUT /computers/{id}/schedule that says retention decides how long these live without saying what it is.

AUTOMATIC CAPTURES COUNT AGAINST YOUR SNAPSHOT STORAGE ALLOWANCE. Their bytes count toward it, so they can bring an account to the point where a manual capture answers 402, and a scheduled capture can be skipped rather than taken when it is full, or on a new account or a newly placed computer until the next complete hourly measurement reaches its host — see PUT /computers/{id}/schedule. Retention is what ages them out, and each plan’s allowance is sized to hold what its retention keeps.

It is a grandfather-father-son window, not an age. What survives is the NEWEST automatic snapshot in each of the last daily DAYS THAT HAVE ONE, the last weekly such ISO weeks and the last monthly such calendar months; every other automatic one goes. So a daily schedule on {"daily": 7, "weekly": 4, "monthly": 12} leaves you 7 days of dailies, then one a week going back a month, then one a month going back a year — at most twenty-three snapshots per computer in a steady state rather than 365, since one capture can be the newest of its day, its week and its month at once.

COUNTED IN PERIODS THAT CONTAIN A SNAPSHOT, NOT IN CALENDAR TIME, and the difference shows up the moment captures stop. Turn a schedule off for a month and come back: the last daily days of history are still there, because those are the last daily days that HAVE a snapshot and not the last daily days on the calendar. Nothing ages out for the passage of time alone, and the most recent automatic capture is kept whatever these numbers say.

PERIOD BOUNDARIES ARE UTC — days, ISO weeks and calendar months are all cut in UTC, whatever tz your schedule runs in. A capture at 23:30 on a Sunday in America/Chicago lands on Monday UTC and so counts toward the following ISO week, which is the one place a schedule set in local time and a window measured in UTC visibly disagree.

A zero turns that tier off, and all three zero means your plan grants no retained automatic history at all — which is what an account with no active subscription reads.

THAT DOES NOT MEAN YOUR EXISTING SNAPSHOTS GO. An account whose subscription lapses keeps a rolling week of its automatic snapshots — deliberately more than the all-zero answer above promises, so that an expired card is not also a lost backup. It is a grace period and not an entitlement: it is not guaranteed, it is not readable here, and it can change. If there is a capture you need to survive any window at all, take one by hand — those are never aged out.

ONLY SNAPSHOTS WITH auto: true ARE TOUCHED. One you took yourself with POST /computers/{id}/snapshots is yours until you delete it, whatever this says, and taking one by hand is how you keep something past the window. The state this ages out is durable — see state on Snapshot.

These numbers are your plan’s, so they change when your subscription does. They belong to the ACCOUNT but are applied PER COMPUTER: the same window is used for every computer you own, and each one keeps its own set. Two computers on {"daily": 7, "weekly": 4, "monthly": 12} keep up to twenty-three snapshots each, not twenty-three between them.

Requires the viewer role or higher.

get/retention

Request

  • Base URL: https://app.mandala.computer/api/v1
  • URL: https://app.mandala.computer/api/v1/retention
  • Auth: HTTP bearer

Response

What your plan keeps.

dailyinteger required

How many of the last days keep their newest automatic snapshot.

weeklyinteger required

The same, over ISO weeks.

monthlyinteger required

The same, over calendar months.

Changes

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