diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx
index bc02c23faa0c2..dfc0f07346bf5 100644
--- a/develop-docs/sdk/telemetry/logs.mdx
+++ b/develop-docs/sdk/telemetry/logs.mdx
@@ -400,7 +400,9 @@ A new data category for logs has been added to Relay, `log_item`. Both the `log`
 
 SDKs **MUST** buffer logs before sending them. SDKs should keep a buffer of logs and flush it when specific conditions are met. For initial implementation, a simple strategy is fine, for example: flushing logs if the buffer length exceeds 100 items or if 5 seconds have passed. To prevent data loss, the buffer SHOULD forward logs to the transport in the scenarios outlined in the [telemetry buffer data forwarding scenarios](/sdk/telemetry/telemetry-buffer/#data-forwarding-scenarios).
 
-SDKs **MUST** also have a hard limit of 1000 log events queued up to avoid causing your customers' applications going out of memory. Logs added once this hard limit has been reached are dropped. Also, Relay has a hard limit of 1000 logs per envelope. SDKs **MUST** not exceed this limit. SDKs **SHOULD**  batch logs into envelopes of 100 or less.
+Relay is optimized for up to 100 logs per envelope. SDKs **MUST NOT** send more than 100 logs per envelope.
+
+To prevent out-of-memory issues in customer applications, SDKs **MUST** enforce a hard limit of 1000 queued log events. Any logs added beyond this limit are dropped. SDKs **MAY** use a lower limit but **MUST NOT** exceed 1000.
 
 We used to recommend following the [BatchProcessor](/sdk/telemetry/telemetry-buffer/#batchprocessor-v0), but this page is currently under development. We currently working on a new [telemetry buffer specification](/sdk/telemetry/telemetry-buffer/) that will replace the BatchProcessor.