Skip to main content
Zero risk Debug statements that weren’t meant to ship. console.log("here"), print(f"DEBUG: {x}"), TODO: remove this. Developer breadcrumbs that made it to production.

​
Why it happens

Engineers add debug statements while developing. Most get removed before merge. Some don’t. Code review catches obvious ones, but logger.debug() calls blend in. Over time, they accumulate. Nobody intends to ship debug logs. But every codebase has them.

​
Example

{
  "@timestamp": "2024-01-15T10:30:00Z",
  "service.name": "checkout-api",
  "severity_text": "DEBUG",
  "body": "got here lol"
}
Tero generates a policy to drop this specific log event: 
id: drop-debug-got-here-checkout-api
name: Drop "got here" debug log from checkout-api
description: Debug statement that shipped to production. Not used in any dashboard or alert.
log:
  match:
    - resource_attribute: service.name
      exact: checkout-api
    - log_field: body
      exact: "got here lol"
  keep: none

Open PRs

Fix at the source. These are code mistakes, not infrastructure decisions.
 Unlike most policy types, leftover debug logs should be fixed in code. The log statement shouldn’t exist. Opening a PR to remove it fixes the problem permanently.

​
How it works

Tero evaluates each log event in your Master Catalog. It looks at the content, the severity, the service context, and whether the log appears in any dashboards or alerts. A log with severity_text: DEBUG might be intentional. But a log that says “got here lol”, has DEBUG severity, and never appears in any dashboard or alert? That’s clearly a debug statement that shipped by accident. Tero flags it and generates a policy you can approve or dismiss.