feat(#10280): document the replication_interval_minutes setting

content/en/building/navigation.md

@@ -71,7 +71,7 @@ Triggering a manual sync by clicking the "Sync now" button will provide feedback
 #### Synchronization Triggers
 - **On Login**: Synchronization is automatically initiated upon successful user login if the app is connected to the internet.
 - **Manual**: Clicking the "Sync now" button.
-- **Periodic Sync**: The application performs regular checks and attempts to synchronize. The main application database syncs every 5 minutes, while the user metadata database syncs every 30 minutes..
+- **Periodic Sync**: The application performs regular checks and attempts to synchronize. The main application database syncs every 5 minutes, while the user metadata database syncs every 30 minutes (configurable with [`replication_interval_minutes`](/technical-overview/data/performance/replication/#replication-interval)).
 - **On Reload**: Synchronization is automatically initiated when the user reloads the application, refreshes the page, or clicks the reload button in the "Update available" modal.
 - **On Connect**: The app also detects when an internet connection becomes available and attempts to sync immediately.
 

content/en/building/reference/app-settings/_index.md

@@ -54,6 +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 |
 
 ## SMS Workflows
 

content/en/technical-overview/data/performance/replication.md

@@ -6,6 +6,7 @@ description: >
   Settings for downloading copies of data onto a user's device
 keywords: 
 relatedContent: >
+  building/reference/app-settings/
   building/reference/app-settings/replication_depth
   community/contributing/code/troubleshooting/replicating-production-data-locally
 aliases:
@@ -203,3 +204,11 @@ Some reports need to be signed off by a supervisor even though that supervisor d
 ### Sensitive documents
 
 We won't replicate reports that are `private` and are about the user when the sender is someone the user can't access. A report is private when it has a property `doc.fields.private` with a value of `true`. For example, if a supervisor submits a private report about one of their CHPs, that CHP won't be able to see it.
+
+## Replication interval
+
+_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.
+
+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.