FoundationDB read‑only secondary configuration lacking explicit staleness limit

FoundationDB’s read‑only secondary feature lets operators offload snapshot reads to cheaper storage, aiming to cut costs for low‑traffic workloads. The documentation does not specify an upper bound on replication lag or staleness that such a secondary may exhibit when write traffic is minimal, leaving administrators to infer freshness from observed metrics.

What is the maximum replication lag permissible for a read‑only secondary under sustained low‑write traffic? How can administrators configure or enforce a staleness limit for such secondaries? Is there a recommended monitoring approach to verify that lag stays within application‑specific freshness thresholds?