From c9ec3badcc1ae06ee46438dab2db58968d535edf Mon Sep 17 00:00:00 2001 From: da_caruso Date: Thu, 15 Oct 2026 20:21:10 +0200 Subject: [PATCH] docs(#10280): lower the replication interval maximum to 60 minutes Matches the core change requested in medic/cht-core#11475: longer intervals may not fire while devices sleep. Co-Authored-By: Claude Opus 5.5 --- content/en/building/reference/app-settings/_index.md | 2 +- content/en/technical-overview/data/performance/replication.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/building/reference/app-settings/_index.md b/content/en/building/reference/app-settings/_index.md index 53af54629..f3e881cd5 100644 --- a/content/en/building/reference/app-settings/_index.md +++ b/content/en/building/reference/app-settings/_index.md @@ -54,7 +54,7 @@ The following settings do not need to be specified. They should only be defined | assetlinks | Array of [Digital Asset Links](/building/reference/app-settings/assetlinks) definitions. This is used to associate your CHT instance's domain to your Android app to verify app links. | | 4.7.0 | |sms.clear_failing_schedules | When `true`, scheduled messages that fail to be generated or sent for various reasons (e.g., empty messages, template issues, or general generation failures) are cleared from the instance's processing queue. This ensures that past messages that were unable to be sent do not perpetually remain scheduled. | false | 5.1.0 | |sms.default_to_sender | When `true`, messages without valid recipients are sent to the sender. When `false`, messages without valid recipients are not sent to the sender if they fail to resolve. They remain in scheduled state. | true | 5.1.0 | -| replication_interval_minutes | Interval in minutes for periodic replication by offline users. Accepts numbers from `5` to `1440`. See the [replication documentation](/technical-overview/data/performance/replication/#replication-interval) for more information. | 5 | 5.4.0 | +| replication_interval_minutes | Interval in minutes for periodic replication by offline users. Accepts numbers from `5` to `60`. See the [replication documentation](/technical-overview/data/performance/replication/#replication-interval) for more information. | 5 | 5.4.0 | ## SMS Workflows diff --git a/content/en/technical-overview/data/performance/replication.md b/content/en/technical-overview/data/performance/replication.md index efd04ec59..a291d3557 100644 --- a/content/en/technical-overview/data/performance/replication.md +++ b/content/en/technical-overview/data/performance/replication.md @@ -209,6 +209,6 @@ We won't replicate reports that are `private` and are about the user when the se _Added in 5.4.0_ -Users with offline roles attempt to download data every five minutes by default. You can increase this interval with the [`replication_interval_minutes` app setting](/building/reference/app-settings/#optional-settings). The setting applies to all offline users and accepts numbers from `5` to `1440` minutes. +Users with offline roles attempt to download data every five minutes by default. You can increase this interval with the [`replication_interval_minutes` app setting](/building/reference/app-settings/#optional-settings). The setting applies to all offline users and accepts numbers from `5` to `60` minutes. A shorter interval within this range gives users fresher data but increases server load. A longer interval reduces the number of periodic replication requests and can ease CPU pressure in deployments with many users. For example, a 30-minute interval schedules periodic syncs less often than the five-minute default, but users may wait longer to receive updates from other users. Consider how quickly your workflows need those updates before increasing the interval.