Skip to main content
Deploy Watcher checks production changes as they reach the Production Graph, compares the affected services before and after, and reports problems with evidence. It starts from a deployment or supported infrastructure change. You do not need an incident alert to start the check.
Ask the Anyshift team to enable Deploy Watcher for your project and arrange access to its results. The results page currently requires superuser access.

​
Quickstart

1

Connect your sources

In the same Anyshift project, connect:Connect GitHub or GitLab if you also want Annie to examine the deployed code changes. Keep any sources already connected to this project.
2

Deploy a change

Once enabled, Deploy Watcher checks supported changes automatically when they reach the graph. Detection depends on event ingestion; new services also get time to start.
3

Check the result

Open Agents → Deploy watcher and select a deploy to read its findings and evidence.The page opens on Problems. Use Status to see Watching or Healthy. Next look shows a planned follow-up; Ask Annie continues the investigation.

​
What the agent checks

The watcher connects the deployed change to its workloads, services and dependencies, then checks:
  • Rollout health: progress, restarts, crashes and out-of-memory events on the affected workloads.
  • Application health: available errors, traffic, latency, alerts and other service signals before and after the change.
  • What shipped: deployed versions and the relevant code changes when repository and version evidence are available.
For a new service, it checks that the service came up and behaves as expected rather than inventing a previous baseline. A running pod alone is not proof that the application is healthy.

​
Example: a checkout regression

A new version of checkout-api reaches production. The pods are ready, but requests start failing. The watcher compares the new deployment with the service’s logs and metrics, and checks the code changes when it can map the deployed version to a commit. The result identifies the observed regression, links the supporting evidence and explains any uncertainty. If traffic is still too low to judge, the result can remain unverified and request another look.

​
Understand the result

The default Problems view is not an inventory of every deployment. A completed Unverified run is not included in the current Problems, Watching or Healthy filters; it is not a passed check. A direct link to an available run can still open its details.

​
Follow-up checks

When a rollout is incomplete, evidence is missing, traffic is low or a signal needs more time, the watcher can schedule another look. Later waves of a release can also join its existing conversation. Read the Next look note for the planned time and question. Follow-up checks are bounded, not an indefinite monitoring loop. A problem already reported remains visible even if a later wave is healthy.

​
Supported changes and coverage

Supported event families include:
  • Image changes on Kubernetes Deployments, StatefulSets, DaemonSets and Rollouts.
  • Helm upgrades or rollbacks that change chart or application versions, plus Argo CD syncs and Flux revision updates.
  • ECS task-definition deployments and supported service creations.
  • Managed Kubernetes version changes.
  • Supported network-rule and permission changes, such as security-group, firewall and IAM changes.
The relevant events must reach the project’s graph. A Helm revision bump with no chart or application version change, or an ECS scaling-only change, does not by itself start a deploy check. Excluded namespaces and short-lived services can be skipped.
Check the selected project, whether Deploy Watcher is enabled, and whether the relevant source has reported a supported event. A connected integration alone does not prove that this particular service or change is covered.The watcher processes recent events. Delayed ingestion, service startup delays, release grouping, processing limits or an interruption can affect coverage and timing. An empty Problems view is not a guarantee that every deploy was checked.
The automated deploy-watch run uses read-only tools. It reports what it finds; it does not automatically merge a fix, roll back a release or change infrastructure.Continue with Ask Annie to investigate further. Any subsequent action depends on that conversation’s permissions and the action you request. For the separate incident fix workflow, see Propose Fix.

Root Cause Analysis

Investigate an incident from an alert or an explicit question.

Proactive Detection

Find production risks through scheduled analysis.