# download-artifact unable to find any artifacts, and why

> In GitHub Actions, download-artifact unable to find any artifacts is a version 3 message. Here is what produced it and what version 8 does instead.

Source: https://latchkey.dev/learn/github-actions/github-actions-download-artifact-unable-to-find  
Updated: 2026-09-20

The message download-artifact unable to find any artifacts is older than it looks: that exact string exists only in version 1 of the artifact toolkit, which `actions/download-artifact@v3` and below shipped. It means the run held no artifacts at all, which is blunter than the name you asked for being absent.

## What this error means

A consuming job fails on its download step with a single line and no detail. There is no artifact name, no run id and no hint, because at the point it is raised the action has not got as far as comparing names: it listed the run artifacts and the list was empty. If you are reading this in a current log, check the version pin first, because the current majors do not produce this sentence at all. There is a second oddity on a version 3 pin: the identical sentence is also printed as ordinary information when no `name` was given, so the same words mean a dead job in one workflow and a quiet no-op in another.

```Actions log, quoted from download-artifact#220
Error: Unable to find any artifacts for the associated workflow
```

## Common causes

### The run really does hold no artifacts

This is what the sentence means literally, and it is usually true. The producing job was skipped, failed before its upload, or uploaded nothing because its path matched no files. The last of those is the quiet one: the default behavior of an empty match is a warning, so the producing job is green and the run is empty anyway.

### The download is reading a different run

A `workflow_run` trigger, a re-run of one job, or a second workflow expecting the first one output are all reading a run that did not produce the artifact. Version 3 had no way to express a cross-run download at all, which is why workflows from that era often still carry a third-party action for it.

### Upload and download are on different major generations

Version 4 replaced the storage backend, and the two sides have to match. A half-finished migration, where the upload moved to version 4 and a consumer somewhere still said version 3, produced this error on every run, because the version 3 listing could not see anything the version 4 upload had written.

### The workflow is still pinned to version 3

As of 30 January 2025 that is a failure in itself rather than a source of this message. If you are looking at this error in an old run and wondering whether to fix the cause, the answer is that the version pin has to move regardless, and moving it changes the error you will see next time.

## How to fix it

### Check whether the run has any artifacts before anything else

1. Open the run summary and look at the artifacts panel: this error means it was empty.
2. If it is empty, the producing job is at fault and the download only reported it.
3. If it has entries, the download read a different run, and the run id is what to check.
4. Note the action version on both steps: on the current majors this line cannot appear.

### Move both sides to the current majors together

The corrected version of the illustrative pair above, with the upload path fixed and both actions on what the releases API reports as current today: version 7 for upload, version 8 for download. Moving one side alone reproduces the mismatch, so both lines change in the same commit.

```.github/workflows/ci.yml, corrected (illustrative)
build:
    runs-on: ubuntu-latest
    steps:
      - run: mkdir -p out && echo hi > out/app.txt
      - uses: actions/upload-artifact@v7
        with:
          name: app
          path: out
          if-no-files-found: error

  ship:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v8
        with:
          name: app
```

### Put the guard back, because the new version does not fail

A download with no `name` and no `pattern` now succeeds against an empty run. If your job depends on having received something, check for it rather than assuming the step would have stopped. One shell line after the download is enough and it fails in the right place, with a message you wrote.

```Terminal
count=$(find dist -type f 2>&- | wc -l)
if [ "$count" -eq 0 ]; then
  echo "no artifacts were downloaded into dist" >&2
  exit 1
fi
```

### Reassemble a matrix the way version 4 expects

If the workflow that hit this was written when every matrix leg uploaded one shared name, that shape is gone and the migration document names its replacement directly. Upload one name per leg, then download by pattern with `merge-multiple` so the consumer sees the same flat directory it used to see.

```.github/workflows/ci.yml (illustrative)
- uses: actions/download-artifact@v8
        with:
          path: dist
          pattern: app-*
          merge-multiple: true
```

## How to prevent it

- Keep the upload and download majors equal, and change them in the same commit.
- Fail the upload on an empty match so an empty run is impossible rather than silent.
- Assert that a download produced something whenever a later step assumes it did.
- Review pinned action majors on a schedule; a closed-down version fails without warning.

## A minimal workflow that produces it

This file is written for this page and has never been run. It is a version 3 pair, because version 3 is the only place the sentence exists: the producing job uploads nothing, its build step having written to a path the upload did not match, and the consumer asks for a name in a run that holds none. The first job is green.

```.github/workflows/ci.yml (illustrative)
name: ci
on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: mkdir -p out && echo hi > out/app.txt
      - uses: actions/upload-artifact@v3
        with:
          name: app
          path: dist

  ship:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: app
```

## One sentence, two meanings, one dead version

In the version 1 toolkit both download paths begin by listing the run artifacts. The path that takes a name throws when the list is empty; the path that takes no name logs the same sentence and returns an empty result, so the job carries on with nothing downloaded. The difference between those two lines is the difference between a red job and a green one.

None of it runs any more. Version 3 of both artifact actions closed down on 30 January 2025, announced nine months earlier, and the changelog is explicit: the tags stay in the repositories, but "attempting to use a version of the actions after the deprecation date will result in a workflow failure". A workflow still pinned to version 3 now fails before it gets far enough to produce this message.

```actions/toolkit, artifact v1, artifact-client.ts
// downloadArtifact, with a name
throw new Error(`Unable to find any artifacts for the associated workflow`)

// downloadAllArtifacts, with no name
core.info('Unable to find any artifacts for the associated workflow')
```

| Version and inputs | What an empty run does | The line you get |
| --- | --- | --- |
| v3, `name` set | Fails the step | Unable to find any artifacts |
| v3, no `name` | Passes, downloads nothing | The same sentence, as information |
| v8, `name` set | Fails the step | Artifact not found for name |
| v8, no `name` | Passes, downloads nothing | Total of 0 artifact(s) downloaded |

## The current version turned half of this into silence

On version 4 and later the old behavior is gone. A named download that finds nothing raises a different error, which names the artifact and adds a standing hint about expiry and version compatibility. A download with no `name` and no `pattern` does not fail at all: the action logs that it is downloading everything, finds none, and finishes with a count of zero.

That last row is the one to watch, because it is a silent version of the same bug. A job whose purpose is to consume artifacts runs its next step against an empty directory, and what fails is whatever that step does with nothing, under a different name. Moving to the current major removes the guard along with the message.

The rest of the migration is the part people remember: uploads and downloads must use the same major generation, artifacts became immutable, and a matrix can no longer write to one shared name. The `pattern` and `merge-multiple` inputs exist to reassemble what that shared name used to give you.

> Once you are on the current majors, a missing name reports differently: see [GitHub Actions artifact not found for name](/learn/github-actions/github-actions-failed-to-download-artifact-not-found).

## Why there is no recorded run on this page

This page could not carry a reproduction even if the house style wanted one, because the code that emits the line no longer runs anywhere: the version holding it closed down in January 2025 and now fails before reaching it. The log above is quoted from a report filed while it still ran. Everything else is a comparison between two versions of an action, so there is nothing transient and nothing for a runner to repair.

## FAQ

### What does unable to find any artifacts for the associated workflow mean?

That the run being read held no artifacts at all, not that the name you asked for was missing. The check runs before any name comparison. It comes from version 1 of the artifact toolkit, which shipped in `actions/download-artifact@v3` and earlier, so seeing it today means an old pin.

### Is actions/download-artifact v3 still supported?

No. Version 3 of both artifact actions closed down on 30 January 2025, announced in April 2024. The changelog says the tags remain in the repositories but using them after the date results in a workflow failure. Artifacts already uploaded stay readable from the UI and the REST API for their retention period regardless of which version wrote them.

### Why does download-artifact succeed when there is nothing to download?

Because on version 4 and later a download with no `name` and no `pattern` is a request for everything, and everything can legitimately be nothing. The action logs a total of zero artifacts downloaded and the step passes. If the job needs a file to have arrived, check for it yourself after the step, because the action will not.

### How do I download all artifacts from a matrix build now?

Give each leg its own artifact name, then download with `pattern` set to the shared prefix and `merge-multiple: true`, which puts everything in one directory the way a shared name used to. Without it each artifact lands in its own subdirectory, which is why a migrated workflow often finds its files one level deeper than expected.

## References

- [The report quoting this error on a version 3 download step](https://github.com/actions/download-artifact/issues/220)
- [GitHub Changelog: deprecation notice for version 3 of the artifact actions](https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/)
- [actions/upload-artifact migration notes for the version 4 behavior changes](https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md)
- [actions/download-artifact README: pattern, merge-multiple and cross-run inputs](https://github.com/actions/download-artifact)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt