Skip to content

fix: add aggressive timeouts to PostHog telemetry to avoid CLI latency#48

Merged
Soph merged 1 commit intomainfrom
20260116-speed-up-posthog
Jan 16, 2026
Merged

fix: add aggressive timeouts to PostHog telemetry to avoid CLI latency#48
Soph merged 1 commit intomainfrom
20260116-speed-up-posthog

Conversation

@toothbrush
Copy link
Contributor

Description

Every CLI invocation was taking ~1s due to PostHog's default behavior of waiting for telemetry to flush on Close(). This was especially noticeable when the PostHog endpoint was slow or unreachable, and the command (e.g., ./entire help) should return instantly. This made the UX sluggish.

Changes:

  • Set ShutdownTimeout to 100ms (was infinite) to cap Close() wait time
  • Set BatchUploadTimeout to 200ms (was 10s) to cap HTTP request time
  • Add custom HTTP transport with 100ms dial/TLS/response timeouts
  • Add silentLogger to suppress expected timeout warnings

The silentLogger is necessary because with these aggressive timeouts, PostHog will frequently log warnings about dropped messages and shutdown timeouts. These are expected and harmless for best-effort telemetry, but would clutter stderr for users.

Trade-off: Some telemetry events may be dropped if the network is slow. This seems acceptable to me, since telemetry is best-effort and should never impact CLI responsiveness.

Co-Authored-By: Claude Opus 4.5 noreply@anthropic.com
Entire-Checkpoint: 9fd2fc39aa5f

Every CLI invocation was taking ~1s due to PostHog's default behavior of
waiting indefinitely for telemetry to flush on Close(). This was especially
noticeable when the PostHog endpoint was slow or unreachable.

Changes:
- Set ShutdownTimeout to 100ms (was infinite) to cap Close() wait time
- Set BatchUploadTimeout to 200ms (was 10s) to cap HTTP request time
- Add custom HTTP transport with 100ms dial/TLS/response timeouts
- Add silentLogger to suppress expected timeout warnings

The silentLogger is necessary because with these aggressive timeouts,
PostHog will frequently log warnings about dropped messages and shutdown
timeouts. These are expected and harmless for best-effort telemetry, but
would clutter stderr for users.

Trade-off: Some telemetry events may be dropped if the network is slow.
This is acceptable since telemetry is best-effort and should never impact
CLI responsiveness.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Entire-Checkpoint: 9fd2fc39aa5f
@Soph Soph merged commit 0ac37f0 into main Jan 16, 2026
3 checks passed
@Soph Soph deleted the 20260116-speed-up-posthog branch January 16, 2026 11:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants