diff --git a/docs/modules/ROOT/pages/system-properties.adoc b/docs/modules/ROOT/pages/system-properties.adoc
index 709b3359e..b57d2c52b 100644
--- a/docs/modules/ROOT/pages/system-properties.adoc
+++ b/docs/modules/ROOT/pages/system-properties.adoc
@@ -1086,6 +1086,7 @@ Stack traces are always reported to the Management Center, but by default, they
 |int
 |Defines a threshold above which a running operation in `OperationService` is considered to be slow.
 These operations log a warning and are shown in the Management Center with detailed information, e.g., stacktrace.
+The value should be set at least 1000 ms. The detector cannot reliably detect all operations taking under 1000 ms.
 
 |`hazelcast.socket.bind.any`
 | true
diff --git a/docs/modules/cluster-performance/pages/threading.adoc b/docs/modules/cluster-performance/pages/threading.adoc
index c9da4c180..5d99de181 100644
--- a/docs/modules/cluster-performance/pages/threading.adoc
+++ b/docs/modules/cluster-performance/pages/threading.adoc
@@ -275,6 +275,8 @@ The `SlowOperationDetector` stores the fully qualified classname of the operatio
 operation details, start time and duration of each slow invocation. All collected data is available in
 the xref:{page-latest-supported-mc}@management-center:monitor-imdg:monitor-members.adoc[Management Center].
 
+The `SlowOperationDetector` is designed to detect relatively long-running operations. Operations are checked every 1,000ms, and due to this scanning mechanism, it cannot reliably detect operations taking less than 1 second (1,000ms). If the slow operation threshold is configured lower than 1,000ms, it may miss operations if they are not running at the time of each scan. If you need to detect operations that take less than 1 second, you should use a JVM profiler. However, use of third-party profiling tools are done at your own risk and should not be used in production environments.
+
 The `SlowOperationDetector` is configured using the following system properties.
 
 * `hazelcast.slow.operation.detector.enabled`
diff --git a/docs/modules/data-structures/pages/entry-processor.adoc b/docs/modules/data-structures/pages/entry-processor.adoc
index 0ffee40c3..9effbe3d1 100644
--- a/docs/modules/data-structures/pages/entry-processor.adoc
+++ b/docs/modules/data-structures/pages/entry-processor.adoc
@@ -150,7 +150,7 @@ We have a slow user code detector which can be used to log a warning controlled
 
 include::clusters:partial$ucn-migrate-tip.adoc[]
 
-The defaults catch extremely slow operations but you should set this much lower, say to 1ms, at development time to catch entry processors that could be problematic in production. These are good candidates for our optimizations.
+The defaults catch extremely slow operations, but you can set this lower at development time to catch entry processors that could be problematic in production. However, detection is not guaranteed, especially for operations with very short execution times (lower than ~1 second), so some operations may not be reported. It is useful as a safety net in development, but it should not be relied on for production or metrics. Entry processors that are detected as slow are good candidates for our optimizations.
 
 We have two optimizations: