Incidents are reasoning problems, not observability problems.

Ask any on-call engineer where the time goes during an incident, and almost none of it is spent staring at a missing metric. The metric is there. The trace is there. The deploy history is there. What is missing is the story — the causal thread that connects a spike in one service to a change made forty minutes earlier in another.

For fifteen years the industry answered every reliability question with more data. More dashboards, more cardinality, more retention. It worked, in the sense that the signal now almost always exists somewhere. But it created a second, quieter problem: assembling that signal into an explanation is still done by a human, under pressure, at the worst possible time.

The signal already exists

This is the uncomfortable truth that observability vendors rarely say out loud. In the vast majority of incidents, no new instrumentation would have helped. The evidence was captured. It sat in three different tools, on two different time axes, described in two different vocabularies, and nobody had stitched it together yet.

That stitching is reasoning. It is the work of forming a hypothesis, testing it against the evidence, discarding it, and forming a better one. It is what a senior engineer does in their head in the first ten minutes of a page — and it is precisely the part we have never automated.

Why now

Two things changed at once. Systems got more entangled: a single user request now fans out across dozens of services, queues, and managed dependencies, so the distance between a cause and its symptom grew. And at the same time, models capable of holding that entangled context and reasoning over it became practical to run in the loop of a live incident.

That combination is the opening. When an incident fires, the right move is no longer to surface more data — it is to reason over the data already collected and hand the responder a causal chain, not a wall of charts.

What this means for tooling

An observability tool optimizes for capture and query. A reasoning tool optimizes for explanation. Those are different objectives, and they lead to different products. The first asks what is the value of this metric right now. The second asks what changed, what did it touch, and which of those changes most likely caused what I am seeing.

Astrea is built for the second question. It turns a live incident into a structured, queryable model of what changed, then reasons over it to point engineers straight at the likely cause — with the reasoning laid out in full, so it can be trusted, corrected, and learned from.