diff --git a/content/en/docs/23.0/user-guides/schema-changes/ddl-strategy-flags.md b/content/en/docs/23.0/user-guides/schema-changes/ddl-strategy-flags.md
index 35a06d70f..06b5c6c7e 100644
--- a/content/en/docs/23.0/user-guides/schema-changes/ddl-strategy-flags.md
+++ b/content/en/docs/23.0/user-guides/schema-changes/ddl-strategy-flags.md
@@ -27,6 +27,8 @@ Vitess respects the following flags. They can be combined unless specifically in
 
   For example, say `--force-cut-over-after=2h`, and that the migration takes `7h` to run. Say there is constant workload/locking that prevents the migration from cutting over. The first cut-over attempt takes place at the end of the `7h` run, and fails due to lock wait timeout. During the next 2 hours there will be multiuple additional attempt to cut-over, and say they all continue to fail. At the `2h` mark (`9h` since starting the migration), give or take, Vitess runs a cut-over that `KILL`s existing queries and transactions on the table. This is likely to make the cut-over successful. Should this still fail, Vitess will continue to forcefully `KILL` queries and transactions in all additional cut-over attempts.
 
+  Any positive duration of `1ms` or less (for example `--force-cut-over-after=1ns` or `--force-cut-over-after=1ms`) is interpreted as _effective immediately_: Vitess will aggressively `KILL` queries and transactions starting with the very first cut-over attempt. The value must be strictly greater than zero.
+
   The flag also works for migrations eligible for `INSTANT` DDL (see `--prefer-instant-ddl`). The same logic that `KILL`s queries and transactions is applied on the migrated table just before issuing the `ALTER TABLE ... ALGORITHM=INSTANT` statement.
 
   See also [forcing a migration cut-over](../audit-and-control/#forcing-a-migration-cut-over)
diff --git a/content/en/docs/24.0/user-guides/schema-changes/ddl-strategy-flags.md b/content/en/docs/24.0/user-guides/schema-changes/ddl-strategy-flags.md
index b26a7a29c..11b92b17c 100644
--- a/content/en/docs/24.0/user-guides/schema-changes/ddl-strategy-flags.md
+++ b/content/en/docs/24.0/user-guides/schema-changes/ddl-strategy-flags.md
@@ -27,6 +27,8 @@ Vitess respects the following flags. They can be combined unless specifically in
 
   For example, say `--force-cut-over-after=2h`, and that the migration takes `7h` to run. Say there is constant workload/locking that prevents the migration from cutting over. The first cut-over attempt takes place at the end of the `7h` run, and fails due to lock wait timeout. During the next 2 hours there will be multiuple additional attempt to cut-over, and say they all continue to fail. At the `2h` mark (`9h` since starting the migration), give or take, Vitess runs a cut-over that `KILL`s existing queries and transactions on the table. This is likely to make the cut-over successful. Should this still fail, Vitess will continue to forcefully `KILL` queries and transactions in all additional cut-over attempts.
 
+  Any positive duration of `1ms` or less (for example `--force-cut-over-after=1ns` or `--force-cut-over-after=1ms`) is interpreted as _effective immediately_: Vitess will aggressively `KILL` queries and transactions starting with the very first cut-over attempt. The value must be strictly greater than zero.
+
   The flag also works for migrations eligible for `INSTANT` DDL (see `--prefer-instant-ddl`). The same logic that `KILL`s queries and transactions is applied on the migrated table just before issuing the `ALTER TABLE ... ALGORITHM=INSTANT` statement.
 
   See also [forcing a migration cut-over](../audit-and-control/#forcing-a-migration-cut-over)
diff --git a/content/en/docs/25.0/user-guides/schema-changes/ddl-strategy-flags.md b/content/en/docs/25.0/user-guides/schema-changes/ddl-strategy-flags.md
index b3d997ac8..3bd6e0e5e 100644
--- a/content/en/docs/25.0/user-guides/schema-changes/ddl-strategy-flags.md
+++ b/content/en/docs/25.0/user-guides/schema-changes/ddl-strategy-flags.md
@@ -27,6 +27,8 @@ Vitess respects the following flags. They can be combined unless specifically in
 
   For example, say `--force-cut-over-after=2h`, and that the migration takes `7h` to run. Say there is constant workload/locking that prevents the migration from cutting over. The first cut-over attempt takes place at the end of the `7h` run, and fails due to lock wait timeout. During the next 2 hours there will be multiuple additional attempt to cut-over, and say they all continue to fail. At the `2h` mark (`9h` since starting the migration), give or take, Vitess runs a cut-over that `KILL`s existing queries and transactions on the table. This is likely to make the cut-over successful. Should this still fail, Vitess will continue to forcefully `KILL` queries and transactions in all additional cut-over attempts.
 
+  Any positive duration of `1ms` or less (for example `--force-cut-over-after=1ns` or `--force-cut-over-after=1ms`) is interpreted as _effective immediately_: Vitess will aggressively `KILL` queries and transactions starting with the very first cut-over attempt. The value must be strictly greater than zero.
+
   The flag also works for migrations eligible for `INSTANT` DDL (see `--prefer-instant-ddl`). The same logic that `KILL`s queries and transactions is applied on the migrated table just before issuing the `ALTER TABLE ... ALGORITHM=INSTANT` statement.
 
   See also [forcing a migration cut-over](../audit-and-control/#forcing-a-migration-cut-over)