Skip to main content
A log statement that fires on every request, every iteration, or every tick. Middleware that logs every incoming request. A loop that logs each item. Code that runs constantly and logs every time. The log statement isn’t wrong. It’s just in the wrong place. These logs made sense during development. They don’t make sense at production scale. This is different from burst protection. Burst protection is for logs that flood during failures. Hot path logs flood all the time, even when everything is healthy.

​
Example

{"body": "Incoming request", "http.target": "/api/users", "service.name": "api-gateway"}
{"body": "Incoming request", "http.target": "/api/orders", "service.name": "api-gateway"}
{"body": "Incoming request", "http.target": "/api/products", "service.name": "api-gateway"}
{"body": "Incoming request", "http.target": "/api/users", "service.name": "api-gateway"}
Thousands per minute. Every request. No additional context beyond what you’d get from metrics.

Open PRs

Remove or relocate the log statement in code.

Create tickets

Alert the team to review the logging pattern.
The fix is in code: move the log outside the loop, add a condition, or remove it entirely. Edge filtering is a temporary workaround, but it doesn’t fix the underlying problem. The code is still doing unnecessary work to generate logs that get dropped.

​
How it works

Tero identifies hot path logs by relative volume. If one event represents a disproportionate share of a service’s logs - say 80% of total volume - it’s in the hot path. That’s the primary signal. The content often confirms it: generic messages like “Processing request” or “Handling item” that fire unconditionally. But volume is what matters.