GitHub Actions: "Artifact not found for name"
actions/download-artifact asked for an artifact by name, and the workflow run had none with that name. The download step is where it fails, but the cause is almost always earlier: in the job that should have uploaded it, or in the name.
What it looks like
Error: Unable to download artifact(s): Artifact not found for name: build
Please ensure that your artifact is not expired and the artifact was uploaded using a compatible version of toolkit/upload-artifact.
For more information, visit the GitHub Artifacts FAQ: https://github.com/actions/toolkit/blob/main/packages/artifact/docs/faq.md
The second and third lines are the same whatever the cause. Without github-token, the step looks only in the current run; from the action's README: "By default, the permissions are scoped so they can only download Artifacts within the current workflow run."
1. The upload found no files and only warned
actions/upload-artifact defaults to if-no-files-found: warn. When its path matches nothing, it logs "No files were found with the provided path", passes, and makes no artifact.
- In kroxylicious, a script stopped writing the release notes, the staging workflow reported success, and the promote workflow failed with
Artifact not found for name: RELEASE_NOTES(kroxylicious #5060). - In pyvista, after a docs setting change no notebooks were written, the upload skipped the empty artifact, and every docs build on main failed downloading it (pyvista #9533).
Open the upload step in the job that should have made it and look for that warning. For an artifact another job needs, make it an error, so the run fails where the files went missing:
- uses: actions/upload-artifact@v7
with:
name: release-notes
path: dist/release-notes.md
if-no-files-found: error
2. The uploading job had not run, or had not finished
- GitHub's documentation: "Jobs that are dependent on a previous job's artifacts must wait for the dependent job to complete successfully." Jobs with no
needsbetween them start together. In lean-workers-union the deploy job and the site job both needed only the test job, so the deploy sometimes reached its download first, and runs on main passed or failed by which got there first (lean-workers-union #7). - A job is skipped when a job it needs fails or is skipped, unless its
if:lets it run anyway. Withalways()or!cancelled()it runs, and the download fails. In butler, when a path filter skipped the Windows build, the end-to-end jobs still ran and failed withArtifact not found for name: windows-e2e(butler #1037).
List the uploading job in needs. If the job has to run after failures too, also check that job's result:
deploy:
needs: [test, build-site]
if: ${{ !cancelled() && needs.build-site.result == 'success' }}
3. A re-run of failed jobs, with the run attempt in the name
"Re-run failed jobs" (or gh run rerun --failed) runs the failed jobs again, not the ones that passed; those keep their result, and their artifacts, from the earlier attempt. github.run_attempt "begins at 1 for the workflow run's first attempt, and increments with each re-run." So a name built from it asks for an artifact that no job uploaded in this attempt:
- Attempt 1 uploaded
nddev-source-39616558599-1-release; the re-run's deploy asked fornddev-source-39616558599-2-release(std-0004-ci-cd-workflows #111). - The same in afactory #562 (
validation-plan-2) and moskophoros #172 (plan-4, while the run held onlyplan-1).
Leave run_attempt out of names that one job hands to another. A re-run then downloads the earlier attempt's artifact, and when the uploading job runs again and uploads the same name, the download takes the newest one (in the toolkit's source: "More than one artifact found for a single name, returning newest"). If the files must come from this attempt, re-run all jobs instead.
4. The artifact is in another workflow run
A release workflow that downloads what CI built has to say where. GitHub's documentation: "If you want to download artifacts from a different workflow or workflow run, you need to supply a token and run identifier."
on:
workflow_run:
workflows: [CI]
types: [completed]
jobs:
release:
runs-on: ubuntu-latest
permissions:
actions: read
steps:
- uses: actions/download-artifact@v8
with:
name: app-apk
github-token: ${{ github.token }}
run-id: ${{ github.event.workflow_run.id }}
For another repository, add repository: owner/name and a token that can read that repository's Actions. The name still has to match exactly: in tucaVR, CI uploaded VR-Player-APK-<branch>-<run id> and the release workflow asked for VR-Player-APK-main, which never existed (tucaVR #79).
5. The artifact has another name
archive: false, new in upload-artifact v7.0.0 (February 2026), uploads one file unzipped. From the release notes: "Thenameparameter is also ignored with this setting. Instead, the name of the artifact will be the name of the uploaded file." Download it by the file name, such asname: my_files.tar.- Matrix jobs need different names, such as
binary-${{ matrix.os }}, so a plainname: binaryfinds nothing. Usepattern: binary-*withmerge-multiple: true. A pattern that matches nothing downloads nothing and does not fail, so check the files after it.
6. It expired
Artifacts are deleted after their retention period: 90 days by default, less with retention-days or a shorter repository or organization setting. In DiluxOne's workflow an artifact kept for one day was gone when the failed jobs were re-run 29 hours later (DiluxOne .github #56). A run can be re-run for 30 days, so keep artifacts that a re-run needs at least as long as you may re-run.
Telling it apart
- The upload step failed: "Artifact storage quota has been hit", or a conflict because matrix jobs uploaded under one name. Then the download is only the second failure.
- On GitHub Enterprise Server, v4 and later stop with "not currently supported on GHES" instead; the README says to use v3 there.
- Right after an upload in the same job: two reports from October 2026 saw the artifact listed a moment after the download failed (audio-pipeline #779, loop-protocol #2969). Neither found the cause.
- Caches are separate from artifacts: "Cache not found for input keys" is
actions/cache.
See failed jobs from IntelliJ IDEA
Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).
GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.
More: "No files were found with the provided path" · "Artifact storage quota has been hit" · Re-running a run over a month old · GitHub Actions plugins for IntelliJ IDEA compared · 日本語