Skip to main content
Tero shows the state of your telemetry estate: the issues that need review, the policies that can fix them, and the impact of those policies at runtime. Datadog, Splunk, collectors, and pipelines remain the systems where telemetry lives. Tero is the control layer above them.
Issues are the main entry point for telemetry policy control.

Issues are the main entry point for telemetry policy control. Open in demo

Tero helps you control telemetry policy. It finds issues across cost, compliance, and signal quality. Each issue includes evidence, provenance, impact, and a recommended policy or action. You review the evidence before you decide what should change. Policies are control-plane artifacts. Tero presents them with status, source, spec, related issue, deployment state, and measured activity. The control plane owns durable policy state; your providers, repositories, collectors, and Edge instances run the changes. The workflow:
  1. Issues: Tero shows what it found and the cost or exposure behind it.
  2. Policies: you review the policy that would address the issue.
  3. Runtime: Tero shows where the policy runs, including provider configuration and Edge instances.
  4. Impact: Tero measures whether the issue, cost, or compliance exposure changed after action.

Why telemetry needs control

Telemetry grows through local decisions. A team adds a debug log during an incident. A health check logs once per second, long after anyone reads it. Two libraries use different names for the same field, so it ships twice. Each change can make sense in isolation, but together they raise your bill and bury the signals you rely on. Pipelines move and transform data, and providers store and query it. Tero adds the missing control loop: find the issue, show the evidence, propose the policy, track runtime state, and measure the result.

Where to start

Start with Issues if you have Tero connected and want to understand the main workspace. Use How Tero works for the full control loop.