Skip to main content
Code that runs on most requests or records emits hot-path logs without conditions. Common sources include request middleware, item-processing loops, and polling loops. This category is distinct from burst protection. Burst protection applies to logs that flood during failures. Hot-path logs produce high volume even when the service is healthy.

Signals

SignalDescription
Disproportionate volumeOne event shape represents a large share of a service’s logs.
Generic message textMessages such as Incoming request, Processing item, or Handling request repeat with little diagnostic context.
Unconditional emissionThe log appears on every request, item, or loop iteration.
Healthy-state volumeThe pattern occurs during normal service operation, not only during incidents.

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"}

Open PRs

Remove, relocate, or condition the log statement in code.

Create tickets

Ask the owning team to review the high-volume logging pattern.
The durable remediation is a code change. Edge filtering can reduce downstream volume, but the service still performs the work required to create the log event.

Detection notes

Tero identifies hot-path logs by relative volume. If one event shape represents a disproportionate share of a service’s logs, Tero treats the event as a hot-path candidate. Message content can support detection. Generic messages such as Processing request or Handling item often indicate unconditional logging, but volume is the primary signal.