Timeline policy configured to retain one daily, two weekly, three monthly snapshot sets:

root@f42-snapm-vm1:~/src/git/snapm# snapm schedule show daily
Name: daily
Sources: /, /var
DefaultSizePolicy: 5%SIZE
Calendarspec: daily
Boot: no
Revert: no
{{GcPolicy: }}
Name: daily
Type: Timeline
Params: keep_monthly=3, keep_weekly=2, keep_daily=1
Enabled: yes
Running: yes
NextElapse: 2025-11-13 00:00:00

The daily snapshot is taken at 00:00, and then immediately deleted by the subsequent GC timer:

Nov 12 00:00:52 f42-snapm-vm1 systemd[1]: Starting snapm-create@daily.service - Create daily snapshot sets...
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: SnapsetName: daily.0
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: Sources: /, /var
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: NrSnapshots: 2
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: Time: 2025-11-12 00:00:53
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: UUID: 352ebc2a-a9c7-5b8c-9fbe-a414db764093
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: Status: Active
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: Autoactivate: yes
Nov 12 00:00:54 f42-snapm-vm1 snapm[751257]: Bootable: no
Nov 12 00:10:52 f42-snapm-vm1 systemd[1]: Starting snapm-gc@daily.service - Clean up daily snapshot sets...
Nov 12 01:10:53 f42-snapm-vm1 systemd[1]: Finished snapm-gc@daily.service - Clean up daily snapshot sets.

root@f42-snapm-vm1:~/src/git/snapm# snapm snapset list
SnapsetName Time NrSnapshots Status Sources Mounted

This is a corner case not covered by existing tests (need to understand why the tests in `container_tests/tests/test_schedule.py` have not picked this up - `test_GcPolicyParamsTimeline_evaluate`/`test_GcPolicyParamsTimeline_evaluate_2` simulate 18 months worth of hourly snapshots and gc. EDIT: they don't catch this, because they don't cover sparse retention policies (one or more higher priority categories with `keep_*=0`).

In addition it would be helpful to log what is being deleted (and for complex policies like TIMELINE, why).