Log rate-limit hits for observability

Open Beginner friendly
#18 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
typescript
Domain
backend, observability

Research direction

Start at the rate-limit checks in workers/index.ts:261 and workers/lib/tools.ts:409, then read nearby logging patterns and the 429 response paths. Add one structured log at each site containing the proposed fields while preserving the response shape, and verify both paths emit the expected observability data.

Written by the indexing model from the issue text.

Description

Rate-limit checks return 429 with no log, so we have no signal in production for whether limits are firing, who is hitting them, or whether thresholds need tuning.

Sites
Proposal

Before the 429 response, emit one structured log line with: limit name, mailbox/principal id, current count, limit, and timestamp. Keep the response shape unchanged.

Why

Rate-limit hits are an abuse/incident signal. Without a log we can't answer "is the limit too tight?" or "is something looping?" from the dashboard.

Effort

~5 lines per site.

Dominant language
TypeScript
Stars
8k
Forks
1k
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudflare/agentic-inbox

All issues in cloudflare/agentic-inbox

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.