## TL;DR
A checkpoint upload fails at the storage layer, not the metadata layer: check the file exists and is fully written before upload, check its size against any proxy or service limits on the path, and retry with the client's resumable or chunked upload where available. A checkpoint still being written by training is the classic silent cause, since the file opens but changes size mid-upload.

```text
how to fix Neptune 'FileUploadFailed' error when uploading model checkpoint artifact
```

## Use this when
- The run or call fails with this symptom: FileUploadFailed from Neptune when uploading a model checkpoint artifact.
- You are working on a Neptune run uploading a model checkpoint at epoch end and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- An upload failing on permissions for the project's storage, where the fix is the workspace storage settings.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Confirm the checkpoint file's size is stable by statting it twice a few seconds apart before upload. Verify: the file is finished and unchanging
2. Upload a small test file through the same client path to separate file problems from path problems. Verify: the test upload succeeds or fails informatively
3. Check the checkpoint size against documented upload limits and any proxy limit in front of a self-hosted server. Verify: the binding limit, if any, is named
4. Upload after training fully closes the file, or copy the checkpoint to a snapshot name and upload the copy. Verify: the checkpoint appears in the run's files

## Variant phrasings
### neptune fileuploadfailed checkpoint artifact
The verbatim phrasing.
### neptune upload failed model checkpoint file still writing
The still-writing phrasing.
### neptune run upload artifact error fix size limit
The limit phrasing.

Compatibility: Neptune file and artifact uploads from runs

## Why it happens
Upload verifies size and checksum against what the client announced at start. A file still growing under it, or a hop with a smaller body limit, fails the transfer at the end, and the client reports only the Neptune-level upload error.

## Edge cases / pitfalls
- Saving checkpoints atomically, write to temp then rename, removes the still-writing class entirely.
- Very large checkpoints belong in object storage with the run holding a reference, not in run file storage.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lcplfOZuIko0dDBScdH_zA