"What changed?": the question behind every incident, and how to answer it in seconds.

October 2026 · 7 min read

Ask any on-call engineer what they do first when an alert fires, and you'll hear some version of the same answer: figure out what changed. Systems that were fine an hour ago don't usually break on their own. Something moved: a deploy, a config change, a feature flag, a dependency, a traffic pattern.

The question is simple. Answering it is not, and that gap is where a lot of incident time goes.

Why "what changed?" is so slow to answer

The answer is usually spread across tools that don't talk to each other:

The symptom is in your metrics tool: error rate up, latency up.
The errors are in your error tracker: a new exception, a spike in an old one.
The deploys are in GitHub or GitLab, or in a CI system, or in a chat channel where someone posted "shipping now".
The context is in people's heads: "oh, we rotated the keys today".

Each tool answers its own piece in seconds. Putting the pieces together, under pressure, at 3am, takes far longer. And every minute spent assembling the timeline is a minute the problem keeps hurting users.

How to answer it faster, with or without tooling

Put deploys where the symptoms are

If your dashboards show deploy markers, the most common answer is visible at a glance: the line goes up right after a release. Most monitoring tools support this; it just needs your CI to send the event.

Use the same service name everywhere

If a service is payments-service in your metrics, payments-api in your error tracker and acme/payments in source control, every lookup starts with a translation step. Consistent naming (or at least a written mapping) makes correlation much faster, for people and for software.

Write down the changes that don't go through CI

Config changes, feature flags, infrastructure tweaks and manual fixes often leave no trace near the symptom. A shared changelog channel, however informal, turns "did anyone touch anything?" into a search.

Watch each release on purpose

Instead of waiting for an alert, compare error rate and latency for a while after every production deploy against the minutes before it. A regression caught during the release is much cheaper than one caught by a customer.

The traps in "it was the deploy"

Deploy correlation is powerful, and it's also easy to get wrong:

Timing isn't proof. A deploy three minutes before the alert is a strong lead, not a conclusion. Check whether the new errors started after it, and whether the affected code is actually in that deploy.
One service or many? If five unrelated services degraded at once, the deploy to one of them probably isn't the cause. Look for a shared dependency instead.
Several deploys in the window. Busy teams ship often. Narrow it down by service and by what changed, not just by time.
Nothing deployed at all. That's an answer too. It points toward traffic, dependencies, data or infrastructure, and saves you from staring at the release history.

Rolling back: the fastest fix, when it's the right one

When the evidence points clearly at a deploy, rolling it back is often the quickest way to stop the damage, even before anyone understands the bug. The point of answering "what changed?" quickly is to make that call with evidence instead of instinct, and to avoid rolling back a perfectly good release while the real cause carries on.

How Cova answers it

This question is the core of what Cova does. When error rate or latency on a service goes wrong, Cova looks up the latest deploy to that service in GitHub or GitLab, checks whether new errors appeared since, compares the same metric on other services to tell "one service" from "many", and posts the finding in Slack with the evidence and how confident it is. If nothing was deployed, it says so.

Cova also watches every production release on its own, and if your services have different names in different tools, you can map them once so every lookup uses the right name. When a rollback is the answer, Cova proposes it with the evidence for a person to carry out.

For the bigger picture of what an agent like this should and shouldn't do, see What is an AI SRE agent?

Know what changed before you open a dashboard.

Try Cova free →