A senior engineer gets a message: the orders API is slow.
Within a couple of minutes she has four tabs open. A latency graph that has started climbing. A deployment that went out minutes earlier. The pull request behind it, changing how the service talks to its cache. A Teams thread where two people are already asking whether checkout feels sluggish.
She has not diagnosed anything yet. But she has already done something none of those tools did for her: she connected them. The deployment, the graph, the change and the conversation each arrived as a separate fact, and she assembled them into a single working picture of what might be happening.
That assembly is the real work. And almost none of it was done by the tools in front of her.
Engineers already do this in their heads
Watch what the engineer is actually holding in mind. This deployment came from that pull request. That pull request touched the cache path. The cache sits in front of the database. Latency rose shortly after the deploy landed. The people in Teams are describing the same symptom she is looking at on the graph.
Each of those links is provisional. Any one of them could be a coincidence. But together they form a hypothesis worth testing, and a sensible order in which to test it.
The point is that this is integration and contextual reasoning done by hand: from memory and open tabs, under time pressure, with a customer-facing symptom and an audience waiting.
Our tools don't
The reason she has to do it by hand is that each system sees only its own slice of what happened.
The deployment platform sees a deployment. Monitoring sees a latency spike. GitHub or Azure DevOps sees a pull request merge. Teams sees a conversation. The incident tool, once someone declares an incident, sees an incident. Every one of these is correct within its own boundary and blind just past it. The deployment platform does not know the deploy came from that PR; monitoring does not know the spike sits on the service that PR changed.
The gap is not inside the tools. It is in the space between them, and that space is where the engineer lives during an incident.
More events do not equal more understanding
The instinct, when investigation is painful, is to add more: more dashboards, more alerts, more telemetry. It rarely helps as much as expected, because the responder was never short of events. They were short of the relationships between them. Another stream is another tab.
It helps to be precise about the difference between an event and its context.
An event is a fact in isolation:
Deployment v2.4.1 completed at 09:47.
Context is that same fact placed among its neighbours:
Deployment v2.4.1 changed the orders service's cache path. Latency on that service began rising shortly afterwards. Engineers reported slow checkout. The service recovered after the change was rolled back.
The second description is far more useful, but notice why. It is not because it proves the deployment caused the problem. It does not. A deployment landing minutes before a latency rise, in the affected service, is evidence worth looking at first; it is not, on its own, proof of anything. The context does not hand you a verdict. It hands you a place to start and a sense of what to weigh, which is exactly what the first description withholds.
Relationships create context
The move from a stream of events to something you can reason about is a move from a list to a set of relationships.
This deployment came from this pull request. This pull request changed this service. This service depends on that component. These metrics moved after the deployment. Engineers began describing a matching symptom. An alert fired against the same service. A rollback followed. The metrics recovered. A similar sequence happened three weeks ago.
Taken one at a time, most of these facts are weak. Deployments happen constantly. Metrics wobble. People complain in chat. Consider what it means for them to line up: the same service, the same time window, the same symptom showing in monitoring and being described in chat, a change that fits, an echo of a previous incident. Even lined up like that, they do not add up to proof. They add up to a stronger reason to investigate one hypothesis ahead of the others. Context is what you get when you stop treating these as separate feeds and start treating them as connected evidence.
It helps to picture engineering activity not as a set of parallel streams but as a connected model. Call it an engineering context graph, if you want a name for it: services, repositories, pull requests, deployments, dependencies, metrics, incidents, engineers and conversations, joined by the relationships between them. The name matters less than the shape of the idea. The value lives in the connections as much as in the things being connected.
Context makes better reasoning possible
Once those relationships exist, the questions you can ask change.
Instead of "did an alert fire?", you can ask what changed before the alert, which systems were involved, what other evidence points the same way, and what happened when engineers responded. Instead of "was there a deployment?", you can ask which deployment touched the affected service, what it changed, and whether the surrounding evidence strengthens or weakens the case that it matters.
That last part is the point. A connected model lets you weigh a hypothesis rather than simply assert one. It can rank a suspicious deployment as the obvious place to begin and still decline to call it the cause until the evidence closes the gap. Reasoning that starts from connected evidence tends to stay honest about what it does not yet know, which is not something you can say of a confident answer assembled from a single signal.
Why this matters beyond incident response
Incidents are where the absence of context hurts most, because the reconstruction happens against the clock. But the same connected understanding is useful long before anything breaks.
Reviewing a risky change is easier when you can see which services the PR touches, what depends on them, and how similar changes have behaved before. Working out who to pull into a problem is easier when ownership is a live relationship rather than a stale wiki page. And learning is easier when a similar sequence next quarter can be recognised as similar, instead of investigated from scratch as though it had never happened.
The connective tissue you build to get through one incident keeps its value after that incident closes. Which raises a question worth a post of its own: if this context is this useful, it is probably worth retaining and being able to replay, rather than discarding the moment the pager goes quiet.
The layer between the tools
Most engineering tooling is built to see one thing well, and it should be. But the understanding an engineer actually needs lives in the relationships between those tools. Today that connective work is done in someone's head, at the worst possible moment to be doing it.
That is the gap Ember is being built around: preserving the relationships between engineering activity so that evidence can be understood in context, rather than rediscovered from scratch every time an incident starts.
Your tools will keep seeing events. The work is making sure the context your engineers assemble in their heads is not thrown away the instant they close the tabs.