Skip to main content
A debug-mode policy category applies when a production service emits DEBUG-level logs for longer than an expected investigation window. This is a service configuration issue: log levels come from environment variables or configuration files, and those changes may not follow the same review path as application code.

​
Signals

SignalDescription
Persistent DEBUG volumeA service emits DEBUG logs beyond the configured threshold.
Sudden level changeDEBUG volume jumps from the service’s previous baseline.
Service-scoped patternThe pattern is evaluated at service level rather than per individual log event.
Production environmentThe logs come from production or another environment where persistent DEBUG logging signals a problem.

​
Example

{"severity_text": "DEBUG", "body": "Entering getUserById", "service.name": "user-service"}
{"severity_text": "DEBUG", "body": "Cache miss for user 12345", "service.name": "user-service"}
{"severity_text": "DEBUG", "body": "Querying database", "service.name": "user-service"}
{"severity_text": "DEBUG", "body": "Query took 3ms", "service.name": "user-service"}
{"severity_text": "DEBUG", "body": "Exiting getUserById", "service.name": "user-service"}

Create tickets

Notify the service owner that DEBUG logging is still active.

Open PRs

Change the log level when service configuration is managed as code.

Enforce at edge

Apply temporary volume control when you can’t change the configuration right away.
The preferred remediation is a configuration change at the source. Edge enforcement is a temporary control for persistent high-volume DEBUG output.

​
Detection notes

Tero detects this category from service-level log patterns: a sudden increase in DEBUG logs that persists beyond a configured threshold. DEBUG logs during an active incident are expected. DEBUG logs that continue for days mean someone forgot to revert the configuration.