diff --git a/specs/agents/tracing-instrumentation-aws-lambda.md b/specs/agents/tracing-instrumentation-aws-lambda.md
index 508cc600..8c28d048 100644
--- a/specs/agents/tracing-instrumentation-aws-lambda.md
+++ b/specs/agents/tracing-instrumentation-aws-lambda.md
@@ -291,3 +291,17 @@ Therefore, the Lambda instrumentation has to ensure that data is flushed in a bl
 
 Some Lambda functions will use the custom-built Lambda extension that allows the agent to send its data locally. The extension asynchronously forwards the data it receives from the agent to the APM server so the Lambda function can return its result with minimal delay. In order for the extension to know when it can flush its data, it must receive a signal indicating that the lambda function has completed. There are two possible signals: one is via a subscription to the AWS Lambda Logs API and the other is an agent intake request with the query param `flushed=true`. A signal from the agent is preferrable because there is an inherent delay with the sending of the Logs API signal.
 Therefore, the agent must send its final intake request at the end of the function invocation with the query param `flushed=true`. In case there is no more data to send at the end of the function invocation, the agent must send an empty intake request with this query param.
+
+### Flush timeout
+
+Agents SHOULD NOT wait for a successful flush indefinitely.
+In the edge case where the extension takes too much time to respond (e.g. if there's a lengthy GC pause),
+the `flush` method should return after a timeout.
+
+The default timeout is 1s.
+
+### Flushing during a grace period
+
+When the agent calls `flush` during a [grace period](transport.md#transport-errors),
+or when it enters a grace period while flushing,
+the agent MUST immediately return from the flush method.