[PetrHeinz]

Lowers the default TIMEOUT_MS from 1000 to 25, Lambda's minimum. Proposed on top of #5 as its own change, so its cost and benefit can be judged separately.

TIMEOUT_MS is how long Lambda buffers telemetry before it hands it to the extension over the sandbox's loopback. It is not how often the extension sends to Better Stack: that stays one request per invocation, at its end. Since #5 the extension waits for that hand-off at the end of every invocation, and Lambda only hands over the last batch, with platform.runtimeDone, when the buffering window closes. So the window is added to every invocation's duration, whatever the function logged. Measured in the E2E, nodejs22.x x86_64, a handler that logs two lines:

extension	Lambda duration	time the caller waited
before #5 (logs sent during the next invocation, or lost)	344 to 692 ms	1.2 to 1.5 s
#5 with TIMEOUT_MS 1000	1366 to 1428 ms	2.1 to 2.7 s
#5 with TIMEOUT_MS 25	476 to 812 ms	1.1 to 1.4 s

The cost of 25 ms: a function that logs faster than 40 lines per second gets a hand-off every 25 ms instead of every second, at most 40 per second, each a small request on the loopback. Functions that log less often see no difference, since a batch with a single line waits for the window either way. Anyone who prefers fewer hand-offs in long, chatty invocations sets TIMEOUT_MS higher, at that much more time per invocation.

🤖 Generated with Claude Code