> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anyshift.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy Watcher

> Check what changed after a production deployment, compare health signals, and follow up when the result is not yet clear.

Deploy Watcher checks production changes as they reach the [Production Graph](https://docs.anyshift.io/pages/overview/knowledge_graph.md), 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.

> [!NOTE]
>
> 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:

* **Your workloads:** [Kubernetes](https://docs.anyshift.io/pages/integration/kubernetes.md#setup), [AWS](https://docs.anyshift.io/pages/integration/aws.md#setup), [Azure](https://docs.anyshift.io/pages/integration/azure.md#setup-guide), or [GCP](https://docs.anyshift.io/pages/integration/gcp.md#setup-guide).
* **Health signals:** connect your logs, metrics, or error tracking—for example [Datadog](https://docs.anyshift.io/pages/integration/datadog.md#setup-guide), [Grafana](https://docs.anyshift.io/pages/integration/grafana.md#setup-guide), [Sentry](https://docs.anyshift.io/pages/integration/sentry.md#setup-guide), [Splunk](https://docs.anyshift.io/pages/integration/splunk.md#setup-guide), [Elasticsearch](https://docs.anyshift.io/pages/integration/elasticsearch.md#setup-elasticsearch-integration), or [VictoriaMetrics](https://docs.anyshift.io/pages/integration/victoriametrics.md#setup-guide).

Connect [GitHub](https://docs.anyshift.io/pages/integration/github.md) or [GitLab](https://docs.anyshift.io/pages/integration/gitlab.md) 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**](https://app.anyshift.io/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

| Result | Meaning |
| - | - |
| **Problem detected** | The watcher found evidence of a problem. Read the findings and affected scope. |
| **Running** | The current check has not finished. |
| **Rolling out** | The rollout is still in progress. |
| **Watching** | Another look is scheduled; the result is not final. |
| **Checks passed** | The completed check found the deployment healthy based on the available evidence. |
| **Passed, with a note** | The check passed with an observation worth reading. |
| **Unverified** | The available evidence was not enough to confirm health. |

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

> **Which changes can start a check?**
>
> 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.

> **Why is a deploy missing or not yet checked?**
>
> 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.

> **Does the watcher change production?**
>
> 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](https://docs.anyshift.io/pages/product/propose_fix).

## Related

> **[Root Cause Analysis](https://docs.anyshift.io/pages/product/root_cause_analysis.md)**
>
> Investigate an incident from an alert or an explicit question.

> **[Proactive Detection](https://docs.anyshift.io/pages/product/proactive_annie.md)**
>
> Find production risks through scheduled analysis.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.