Deploy correlation is one of the most reliable signals in incident root cause analysis. When something breaks, the first question most experienced engineers ask is: what changed? And "what changed" usually means: was there a deploy? The intuition is sound. A large fraction of production incidents have a deploy as either a direct cause or a contributing factor.
But the usefulness of deploy correlation depends entirely on the window. Too short, and you miss delayed-onset failures that take hours to manifest. Too long, and every incident has a dozen deploys in the correlation window, which provides no useful signal at all. Getting the window right is one of the more consequential and least-discussed configuration decisions in incident tooling.
Why the right window varies by team
There is no universal correct deploy correlation window. The right window depends on at least three factors that vary significantly across teams.
Deploy frequency matters most. A team that ships 20 times a day will have a different noise profile than a team that ships twice a week. At 20 deploys per day, a 6-hour correlation window may include 5 deploys. That's enough to give you a meaningful signal (one of these is probably related) while keeping the candidate set small enough to evaluate. For a team shipping twice a week, a 6-hour window may include zero deploys, and you'd need to extend to 24 or 48 hours to find anything. But a 48-hour window for a high-frequency team would include 40 deploys and give you nothing actionable.
Failure onset latency is the second factor. Some failure modes manifest within minutes of a deploy: the service crashes on startup, a new endpoint returns 500s immediately, a config change causes immediate connection failures. These cases are well-served by short windows (30 minutes to 2 hours). Other failure modes have delayed onset: a memory leak introduced by a new code path may take 6 to 12 hours of traffic to exhaust the available heap. A database migration that adds a poorly-indexed query may be fast under low load and catastrophic under the weekend traffic peak that arrives 18 hours later. For these cases, a short window misses the causal deploy entirely.
The third factor is deploy blast radius. Monolithic deployments or services that are deeply integrated into the request path have a shorter acceptable window for ambiguity: if anything breaks after a monolith deploy, you need to know quickly. Microservice deploys to peripheral services may have more tolerance for longer windows because their failure modes are more isolated and the causal chain takes longer to propagate.
The signal decay curve
The statistical relationship between deploy age and incident causation probability follows a decay curve. In the first 30 minutes after a deploy, the correlation probability is high: if something breaks in this window, there's a strong prior that the deploy is related. This probability decreases with time, but not linearly.
There are two meaningful thresholds in most environments. The first is around 2 to 4 hours. Beyond this point, a deploy that hasn't caused any observable anomalies is probably stable under normal load conditions. The probability of it being the cause of a new incident drops significantly. The second threshold is around 8 to 12 hours. Beyond this point, a deploy has likely been through at least one traffic peak and one off-peak period. Surviving both without incident is a reasonable indicator that it's not going to cause problems under normal conditions.
This doesn't mean deploys older than 12 hours can't be incident causes. They can. Deploys that introduce bugs triggered by rare event combinations, time-based processes (cron jobs, daily batch runs), or load patterns that only appear at specific times can have onset latency of 24 to 72 hours. But these are distinguishable from the common case: they tend to involve specific triggering conditions rather than gradual degradation, and the telemetry signature usually shows a discrete state change rather than a gradual metric drift.
The practical case for a two-window approach
Rather than a single correlation window, we've found a two-window approach more effective for most teams. The first window is a primary correlation window, typically 2 to 6 hours depending on deploy frequency, where deploys are surfaced with full detail and high priority. The second is an extended window, typically 6 to 24 hours, where deploys are surfaced but with reduced priority and an explicit flag: "these are older deploys included for completeness."
This gives the on-call engineer the right anchoring. The most recent deploys get immediate attention. The older deploys are visible but don't generate the same pull. In practice, the right deploy is usually in the primary window. The extended window catches the edge cases without burying the signal in noise.
In Devtract, we implement this as a tiered confidence model. Deploys within 90 minutes of the incident fire with the highest confidence weighting. Deploys between 90 minutes and 6 hours carry a medium weighting. Deploys between 6 and 24 hours are included in the correlation output but marked with a lower confidence modifier. Engineers can see the full picture while still getting a clear signal about where to start.
The services that need custom windows
Some services have failure modes that require customized correlation windows regardless of your default setting.
Batch processing services are the most common exception. If a service processes daily batch jobs starting at 02:00 UTC, an incident at 02:45 UTC should look at deploys from the previous 24 hours, because any deploy from the previous day could be the first time the batch code path has run since the change. A standard 6-hour window would miss yesterday's deploy entirely.
Scheduled job infrastructure is similar: cron jobs, task queues, and asynchronous workers may only exercise specific code paths on their own schedule. The first execution of a daily job that fails might be 23 hours after the deploy that broke it.
Configuration-driven services deserve a separate consideration: if a service has hot-reload for configuration (pulls from a config service or environment every N minutes), configuration changes aren't tracked as deploys in most CI/CD systems. They're a separate change type that needs its own correlation model.
False positives and their cost
The other side of window tuning is false positives. A correlation window that's too wide generates deploy candidates that aren't related to the incident. This has a real cost during active incidents: the on-call engineer spends time investigating or dismissing irrelevant deploys when they could be focused on the actual cause.
We're not saying false positives are catastrophic. An experienced SRE can usually dismiss an unrelated deploy quickly: "That was a frontend CSS change, it can't be related to a database connection pool error." But at 3am, under time pressure, with a war room watching, each false positive adds cognitive load. A correlation window that surfaces 8 deploys instead of 2 doesn't give you more information. It gives you more work.
The right tuning direction: when in doubt, make your primary window shorter rather than longer. You can always ask "show me deploys from the last 24 hours" as a follow-up query. Starting from a short list and expanding is faster than starting from a long list and filtering.
Using incident history to calibrate
The most rigorous way to tune your correlation window is to work backward from your incident history. For each past incident where a deploy was the root cause, record the time between the deploy and the alert that opened the incident. This distribution tells you the actual onset latency profile for your environment.
If 80% of your deploy-caused incidents have onset latency under 90 minutes, your primary correlation window can be tight. If 40% of your deploy-caused incidents have onset latency between 4 and 12 hours, you need to extend the window considerably. The right number isn't a convention or a rule of thumb; it's derived from your actual failure data.
Most teams haven't done this analysis explicitly. The window in their incident tooling is whatever the default was when they set it up. Doing a 30-minute review of the last 20 deploy-caused incidents in your postmortem archive will give you more useful calibration data than any general guidance. The number that comes out of that analysis is the right starting point for your primary correlation window.
Deploy correlation is one of the highest-leverage tools in RCA. Getting the window wrong doesn't break the tool, but it either leaves real signal in the dead zone or buries it in noise. Both outcomes slow down incident response in ways that compound over time. The window is worth tuning explicitly rather than accepting the default.