# High Availability

> What to do on your side so builds keep working when a request to CloudRepo fails: retry only what is worth retrying, keep what your builds have downloaded, keep your own copy of what you cannot rebuild, and check the status page.

This page is about what you can do on your side so that builds keep working when a request to CloudRepo fails.

How CloudRepo hosts your data, where it runs and how it recovers from failures are described on CloudRepo’s [security practices](https://www.cloudrepo.io/security/practices) page, not here.

## When a request fails

[Troubleshooting](/docs/reference/troubleshooting.html) maps each status code to its usual cause. Two groups matter here:

- **`401`, `403`, `404` and `409`** are CloudRepo’s answers to the request you sent: a refused credential, a token that cannot reach the repository, a path that holds nothing, a path that already holds a file. Sending the same request again gets the same answer until you change something.
- **`5xx`, a timeout, or no answer at all** are not about your credential or your request. Check [status.cloudrepo.io](https://status.cloudrepo.io), then try again, then [contact support](/docs/reference/support.html) if it keeps failing.

## Retry what is worth retrying

Let your tools try again on a failure that is not a refusal:

- **curl** retries a transient error when you pass `--retry` with a number. The default is no retries.
- **pip** retries a connection it cannot establish: `--retries` sets how many attempts, and the default is 5.
- **npm** retries idempotent read requests on a network failure or a `5xx`: the `fetch-retries` setting, default 2, sets how many.

**Terminal**

```bash
curl --netrc --fail --retry 3 --output hello-copy.txt \
  https://your-org.mycloudrepo.io/repositories/your-repo/uploads/hello.txt
```

Retry downloads freely. Take more care with an upload. If CloudRepo stored a file and the answer was lost on the way back, a second upload of the same path meets `409 Conflict` while [Overwrite Protection](/docs/manage/repositories.html#overwrite-protection) is on, because the file is already there. On a Maven repository a file in a `-SNAPSHOT` version directory, `maven-metadata.xml` and its checksum and signature files are the exceptions: a second upload of one of those is accepted and replaces the first. See [Maven: SNAPSHOT and Metadata Are Exempt](/docs/manage/repositories.html#maven-snapshot-and-metadata-are-exempt). Check whether the file exists before you publish it again.

## Keep what your builds have downloaded

Maven keeps what it downloads: its local repository is a directory on the machine that “caches remote downloads”. On CI, where each job starts clean, use your CI platform’s cache feature to keep that directory from one run to the next, so a fresh job starts with what an earlier one downloaded.

## Keep your own copy

A build can only use what it can fetch. For releases you cannot rebuild, keep a copy of your own. See [Backup and Recovery](/docs/reference/backup-and-recovery.html).

## Next steps

- [Troubleshooting](/docs/reference/troubleshooting.html): what each status code means.
- [Backup and Recovery](/docs/reference/backup-and-recovery.html): keep your own copy.
- [Support](/docs/reference/support.html): how to write to us.

---

The page: https://www.cloudrepo.io/docs/reference/high-availability.html