diff --git a/docs/SETTINGS.rst b/docs/SETTINGS.rst
index c09826db..7b9265cd 100644
--- a/docs/SETTINGS.rst
+++ b/docs/SETTINGS.rst
@@ -19,6 +19,7 @@ Bootstrap configuration
     -  **maximum\_lag\_on\_failover**: the maximum bytes a follower may lag to be able to participate in leader election.
     -  **master\_start\_timeout**: the amount of time a master is allowed to recover from failures before failover is triggered. Default is 300 seconds. When set to 0 failover is done immediately after a crash is detected if possible. When using asynchronous replication a failover can cause lost transactions. Best worst case failover time for master failure is: loop\_wait + master\_start\_timeout + loop\_wait, unless master\_start\_timeout is zero, in which case it's just loop\_wait. Set the value according to your durability/availability tradeoff.
     -  **synchronous\_mode**: turns on synchronous replication mode. In this mode a replica will be chosen as synchronous and only the latest leader and synchronous replica are able to participate in leader election. Synchronous mode makes sure that successfully committed transactions will not be lost at failover, at the cost of losing availability for writes when Patroni cannot ensure transaction durability. See :ref:`replication modes documentation <replication_modes>` for details.
+    -  **synchronous\_mode\_strict**: prevents disabling synchronous replication if no synchronous replicas are available, blocking all client writes to the master. See :ref:`replication modes documentation <replication_modes>` for details.
     -  **postgresql**:
         -  **use\_pg\_rewind**: whether or not to use pg_rewind
         -  **use\_slots**: whether or not to use replication_slots. Must be False for PostgreSQL 9.3. You should comment out max_replication_slots before it becomes ineligible for leader status.
diff --git a/docs/replication_modes.rst b/docs/replication_modes.rst
index b7d12cda..8bf36d4b 100644
--- a/docs/replication_modes.rst
+++ b/docs/replication_modes.rst
@@ -42,6 +42,15 @@ Turning on ``synchronous_mode`` does not guarantee multi node durability of comm
 
 When ``synchronous_mode`` is on and a standby crashes, commits will block until next iteration of Patroni runs and switches the primary to standalone mode (worst case delay for writes ``ttl`` seconds, average case ``loop_wait``/2 seconds). Manually shutting down or restarting a standby will not cause a commit service interruption. Standby will signal the primary to release itself from synchronous standby duties before PostgreSQL shutdown is initiated.
 
+When it is absolutely necessary to guarantee that each write is stored durably
+on at least two nodes, enable ``synchronous_mode_strict`` in addition to the
+``synchronous_node``. This parameter prevents Patroni from switching off the
+synchronous replication on the primary when no synchronous standby candidates
+are available. As a downside, the primary is not be available for writes
+(unless the Postgres transaction explicitly turns of ``synchronous_mode``),
+blocking all client write requests until at least one synchronous replica comes
+up.
+
 You can ensure that a standby never becomes the synchronous standby by setting ``nosync`` tag to true. This is recommended to set for standbys that are behind slow network connections and would cause performance degradation when becoming a synchronous standby.
 
 Synchronous mode can be switched on and off via Patroni REST interface. See :ref:`dynamic configuration <dynamic_configuration>` for instructions.