If you have configured [Watch Files](Article: #755) on a build command but it runs on every deployment -- even when none of the watched files changed -- the most common cause is that there is **no build cache to restore**.

## Skipping requires a build cache

Watch Files has a second condition that is easy to miss: a build command is only skipped when the [build cache](Article: #167) can be restored onto the build server first.

This is deliberate. The purpose of skipping an install step is that its output -- your `vendor/`, `node_modules/` or similar -- is already present on the build server. That output is only ever restored from the build cache. If we skipped the install when no cache was available, later steps would run against a missing dependency directory and fail.

So a command is skipped only when **both** are true:

1. None of the changed files match the watch patterns, **and**
2. Caching is enabled for the deployment **and** a cache file exists to restore.

If the second condition is not met, the command runs regardless of what changed.

## The most common cause: no cached build files configured

If your project has no entries under **Cached Build Files**, no dependency files are stored between deployments, so there is nothing for a later deployment to restore. A watched build command will keep running on every deployment, and no change to your watch patterns will alter that.

To fix it, head to **Build configuration** within your project's **Build Pipeline** and add a cached file entry covering your dependency directory. For example:

```
vendor/**
```

for PHP and Composer, or:

```
node_modules/**
```

for Node. See [Build Caching](Article: #167) for the full setup.

**The first deployment after adding a cached file entry will still run the command in full**, because it has to populate the cache. Subsequent deployments will be able to skip it.

## Other reasons a cache may be unavailable

Even with cached files configured, the cache may not be restorable on a given deployment:

- **Use build cache? was disabled** for that deployment under advanced settings, which requests a clean build.
- **No usable dependency cache is available** for this branch yet, so there is nothing to restore.
- **The cache was cleaned up.** Build caches are removed automatically after a period of inactivity, so a project that has not deployed for a while may no longer have one.

In each case the watched command runs rather than being skipped. This is the safe fallback, not an error.

## Why so many files transferred afterwards

DeployHQ works out which files to transfer by comparing the finished build against the files it sent to the build server. When no cache was restored, your dependency directory is not part of that comparison, so every file produced by the install is treated as new rather than unchanged.

This is why a deployment that unexpectedly reinstalls dependencies can also transfer the entire dependency tree, even though the files are identical to those already on your server. Configuring a cached build file entry resolves both symptoms together.

## Checking a specific deployment

Open the deployment and look at the **Preparing** stage. When a cache is restored you will see a *Sending cached build to build server* entry. If that entry is absent, no cache was available and any watched build command will have run.