Field notes
Annotating deploys without turning the timeline into clutter
If every microservice stamps a deploy marker with a different name, your impact timeline becomes noise. Agree on a thin convention before you need it during an incident.
Minimum fields
- Service or bounded context name
- Version or change ticket
- Start and end of the deploy window in KST
- Owner on call for the first hour
Avoid vanity markers
Do not annotate every config tweak as a “major release.” Reserve deploy annotations for changes that can plausibly move production behavior. Feature flag flips that affect more than a canary cohort deserve a marker; internal comment-only merges do not.
Review after the fact
During a Deployment Impact Assessment we reconcile annotated times against CI logs. Gaps between “marked done” and “traffic fully cut over” are common — and they explain many false attributions.