The alert fires at 2:14pm.
The deployment landed at 1:51pm. It touched three services, introduced a path that had not been exercised under production traffic, and a reviewer had added a comment that said "this should be fine, but watch the edge cases." The build passed. The deploy completed. Nothing failed immediately.
Twenty-three minutes later, the alert fired.
The incident timeline will say the incident started at 2:14pm. That is when it became undeniable. It is not when it started.
The alert is not the beginning
When a system pages someone, the failure has already happened. A customer may already have been affected. The on-call engineer is not there to prevent the incident. They are there to recover from it.
This is obvious once stated, but incident tooling is almost entirely organised around the alert. The alert creates the ticket. The ticket becomes the incident. The incident captures what the team did after the alert fired.
What came before the alert is missing from the record.
Incidents are not events that begin when the alert fires. They are conditions that develop over time, and the alert is simply when the team finds out.
The signals that explain an incident rarely start at the alert. They start around change: a deployment, a config update, a feature flag, a schema migration. The alert is a lagging indicator. The change is where the story starts.
The deployment timeline lives somewhere else
When an incident starts, the team opens their incident management tool. They see when the alert fired, who was paged, and what actions have been taken so far. That is useful.
What they do not see: what shipped in the last few hours, which services changed, what reviewers noted in code review, which feature flags were toggled in the hour before the alert, what customers started reporting before monitoring caught anything, and what the team was saying in chat.
All of that data exists. It lives in CI/CD pipelines, pull requests, deployment logs, feature flag consoles, support queues, and Slack threads. Each of those systems knows something. None of them talk to each other.
So when the on-call engineer asks "did anything change recently?" they are starting a manual investigation across multiple systems, under pressure, often without the people who made the changes available.
That investigation is where incidents get expensive. Not because teams are slow. Because the context is scattered.
Change correlation is not blame
There is an uncomfortable dynamic that makes this harder than it should be.
When someone asks "what changed recently?" during an incident, people in the room often hear something different: "who caused this?" The engineer who deployed last feels the attention. The reviewer who approved feels it. The team quietly hopes the cause is something external, a dependency, a cloud provider, anything other than the change they shipped.
This conflation is wrong, and it is counterproductive.
A recent deployment is not a confession. A risky PR is not proof. Change correlation surfaces what is plausibly related so the team can investigate efficiently. It does not assign cause, and it should not be used to assign blame.
Change correlation should reduce uncertainty, not assign blame.
The distinction matters for how systems should be built and how teams should use them. A deployment that touched an affected service deserves investigation. It may turn out to be entirely unrelated. The point is to start in the right place, not to close the investigation early.
Teams that conflate correlation with causation do two things wrong: they move too quickly to a conclusion when the obvious candidate looks suspicious, and they stop looking when the obvious candidate is cleared. Both errors extend incidents.
Why time-based correlation is not enough
The simplest form of change correlation is temporal: show everything that changed in the last hour. This is better than nothing, and some teams rely on it exclusively.
But it has real limitations.
Two services may have deployed in the same window, and only one touched the affected path. A deployment may look clean for thirty minutes under normal traffic before failing under real load. A configuration change may have landed hours before the alert, but only matters under conditions that took time to appear. A feature flag may have been toggled by someone who is not in the incident room and does not know an incident is happening.
Pure time-based correlation gives you a list. It does not give you a ranking. It treats all changes as equally likely to matter, which means the team still has to do the work of determining which changes are actually relevant.
The list is a starting point. But a long list of unranked changes, generated under pressure, without context, is not much better than having no list at all.
What better looks like
A more useful system does not just ask "what changed recently?" It asks "what changed that is plausibly related to what is happening right now?"
That requires more than timestamps. It requires:
- Service ownership and dependency maps, so changes can be connected to affected services rather than just sorted by time
- The content of changes, including which paths, files, and components were touched
- PR-level signals, including review comments, the number of reviewers, last-minute changes, and reviewer hesitation
- Customer reports, which often arrive before monitoring catches anything and can narrow the scope considerably
- Past incident memory, so the system can recognise whether this symptom pattern has appeared alongside similar changes before
- Confidence levels, so the team knows when a hypothesis is well-supported and when it is a weak signal worth checking but not betting on
When an incident starts, the team should be able to see a ranked view: here is what changed, here is what touched the affected services, here is what carried risk signals, here is how confident we are, and here is whether this pattern has appeared before.
That is not a declaration of root cause. It is a better starting point.
The right starting point matters
Where an incident team directs its attention in the first fifteen minutes shapes everything: the hypotheses they test, the data they pull, the people they page, the rollback decisions they consider.
Starting in the wrong place is not just inefficient. It compounds. Every dead end costs time. Every correct hypothesis that gets deprioritised extends the incident. The longer an incident runs, the more pressure mounts, and the harder it becomes to think clearly about which signals actually matter.
Getting to the right starting point faster is one of the highest-leverage interventions available.
It does not require better monitoring. The monitoring is usually already telling teams something is wrong. It does not require a bigger incident team. It requires connected context: the deployment that shipped, the review comment that flagged a concern, the customer report that surfaced before the alert, the similar incident that happened six months ago.
That context exists in every engineering organisation. The problem is that it is not connected when the team needs it most.
Where Ember fits
Ember is designed to connect the evidence that already exists across the places where engineering work happens: deployments, code review, observability, team conversation, customer signals, and past incidents.
When an incident starts, that looks like a ranked view of what changed, what touched the affected services, what carried risk signals, and whether any of it matches patterns the system has seen before. With confidence levels, not certainty. With evidence, not assertions.
The goal is not to replace the engineer's judgment. It is to reduce the time spent reconstructing context under pressure, so the investigation starts with the most plausible hypotheses rather than the most recent timestamps.
The gap between when a deployment lands and when an alert fires is where many incidents become harder to understand. Closing that gap is where most of the