Heuristic
Let the change bake before stacking the next one
If you change the experiment before the result arrives, you inherit an explanation problem.
When it fits
- A first change has completed technically but important effects may appear with traffic, queues or delayed jobs.
When to avoid it
- Do not delay urgent remediation just to preserve a clean experiment; incident response can justify immediate follow-on action.
Why it matters
Choose an observation window long enough to expose the failure modes you care about before adding another unrelated change. Watch leading and delayed signals during that time. The point is not idle waiting; it is preserving causal visibility long enough to know whether the current state is healthy.
An example
After changing replication parallelism, observe at least one full processing cycle before also changing retry settings.
Check your result
When a metric moves, the team still has a reasonably interpretable set of recent changes rather than a stack of simultaneous experiments.
Keep this limit in mind
- Do not delay urgent remediation just to preserve a clean experiment; incident response can justify immediate follow-on action.
Connected ideas
Useful withCanary the batch before scaling it
Evidence and sources
AWS identifies rapid follow-on deployments without sufficient bake time as a deployment anti-pattern.
Required observation time depends on traffic, delayed jobs and the failure modes that matter.
REL08-BP05 Deploy changes with automation · Common anti-patterns