Skip to content

feat(#10280): lower the replication interval maximum to 60 minutes #2271

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dacar1988 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat(#10280): lower the replication interval maximum to 60 minutes #2271

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/en/building/reference/app-settings/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion content/en/technical-overview/data/performance/replication.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Loading