volume-snapshots silently not creating on postgres-flex despite Scheduled snapshots: true

Questions / Help
1

App: eziopro-prod-db (postgres-flex 17.2, 3-node HA, jnb region)
Discovered: 2026-05-28 during pre-deploy preparation

Volume snapshots have not been creating on this cluster for ~4 months despite being configured correctly. Specifically:

  1. flyctl volumes show <vol-id> -a eziopro-prod-db reports:
    Snapshot retention: 5
    Scheduled snapshots: true

  2. flyctl volumes snapshots list <vol-id> returns “No snapshots available” for all 3 volumes:

    • vol_40ln1g39o0y5plm4 (primary)
    • vol_vdmwg8okqjoykjkv (replica)
    • vol_4o5glq6e5dkwolxv (replica)

  3. Three manual triggers via flyctl volumes snapshots create <vol-id> on 2026-05-28 returned “Scheduled to snapshot” success acknowledgments, but no snapshots ever appeared in snapshots list even after ~15 minutes of polling.

The volumes themselves are healthy and the cluster is functioning normally (replication, queries, writes all fine). All 3 volumes were created ~4 months ago and the cluster has been operational throughout, so based on retention: 5 and the default daily auto-snapshot schedule, I would expect to see at least 5 rotating snapshots at all times — there are zero.

I’ve since enabled Tigris/WAL backups as a workaround (flyctl postgres backup enable), which is working correctly. But the volume snapshot pipeline being silently broken seems like a meaningful platform issue, especially for users who rely on volume snapshots as their backup mechanism without realizing it isn’t working.

Could you investigate why the snapshot worker hasn’t been creating snapshots for this cluster, and whether other postgres-flex clusters might be affected by the same issue?

Happy to provide additional diagnostic output if useful.

Thanks,
Richmond

2

Hi… As just a quick suggestion, try specifying an explicit -a eziopro-prod-db there…

https://community.fly.io/t/postgres-unreachable-due-to-irreparable-damage-on-host-machine/27891/12

(Logically it wouldn’t be necessary, but newer versions of flyctl seem to require it when listing snapshots.)

4

Hi, can you share verbatim output of flyctl volumes show <vol-id> -a eziopro-prod-db for your affected volumes, flyctl volumes snapshots list <vol-id> for all of them (also verbatim output)? Verbatim output, not llm summaries, might have clues as to what’s going on here.