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 8ce25261f..38cb48f39 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.
 
+  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)
 
 - `--in-order-completion`: a migration that runs with this DDL strategy flag may only complete if no prior migrations are still pending (pending means either `queued`, `ready` or `running` states). `--in-order-completion` considers the order by which migrations were submitted. Note that `--in-order-completion` still allows concurrency. In fact, it is designed to work with concurrent migrations. The idea is that while many migrations may run concurrently, they must _complete_ in-order.