The semantic graph
Your systems produce billions of data points. Tero compresses them into something you can reason about. Billions of log lines become thousands of log events. Millions of spans become trace span patterns. Each has meaning: what it represents, when it matters, which service produces it. Metrics get the same treatment. Not just names and tags, but what they measure and why you’d care. Services tie it together: what they do, what they depend on, how they fail. Relationships are earned, not assumed. The graph starts clean: services own their log events, metrics connect to what they measure, dependencies come from traces. As you investigate issues, successful paths prove new connections. That error you traced from checkout to payments? Now a relationship. The pattern your team discovered? Captured. Every edge in the graph exists because something proved it. This is what lets Tero answer questions. When you ask about waste, Tero doesn’t pattern-match on log text. It evaluates each event against everything it knows: the service context, the failure scenarios, the transaction patterns, the relationships. Understanding, not just parsing.Transparent by design
You can see everything Tero knows. Drill into any service, examine any log event, trace any relationship. When Tero makes a judgment (this log is waste, this metric matters) you can see why. This isn’t a black box that produces answers. It’s a system you can inspect, question, and correct. If Tero misclassifies something, fix it. If context is missing, add it. If a relationship is wrong, adjust it. The goal is a system that feels like yours. You understand how it works. You can get your hands in when needed. You’re not trusting magic. You’re working with a tool you understand.How context grows
1
Integrations bring it
Connect an integration and Tero discovers your services, catalogs your log events, identifies trace span patterns, maps your metrics. Each integration adds nodes and edges to the graph. The more you connect, the richer the picture.
2
Tero enriches it
Background processing adds context you didn’t provide. Tero detects that a service is a Rails app and enriches it with known failure patterns. It identifies common error signatures and links them to debugging approaches. It notices transaction patterns, groups of log events that appear together when processing a request.
3
Conversations refine it
When you chat with Tero, you’re not just getting answers. You’re teaching it. Correct a misclassification and it learns. Explain why a log matters and that knowledge persists. Every interaction sharpens the graph.
Working with context
The primary interface is @ references. In any chat, type@ and reference a service, log event, metric, or past conversation. That context, and everything connected to it, becomes available.
This is the graph in action. Reference a service and you get its description, its dependencies, its failure scenarios, its log events. Reference a log event and you get its attributes, its transaction patterns, which service owns it. The connections come along automatically.
You can also explore context directly. Browse services, drill into their log events, trace relationships. See what Tero knows about any piece of your infrastructure. Adjust what’s wrong. Fill in what’s missing.
The more you use context, the more useful it becomes. Not because you’re configuring things, but because every interaction adds signal about what matters and how things connect.