# Troubleshooting > Fix a failing CloudRepo build: read the status code, test your credential on its own, check the usual address mistakes, and collect a debug log without leaking your token. Start with the status code your client printed. The table maps each one to what to check. ## Read the status code | Status | What it usually means | What to do | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `401 Unauthorized` | CloudRepo refused the credential: the username is not the email address of the account that created the token, the token is expired or revoked, or the address is one CloudRepo does not serve. | [Test the credential](#test-the-credential-on-its-own), then the checks on [Repository Tokens](/docs/authenticate/repository-tokens.html#when-a-client-answers-401-403-or-404). | | `403 Forbidden` | The credential is good, but it may not do this: the token does not reach this repository (`scope_mismatch_repo`), or it is **Read only** and the request writes. | Create a token that includes the repository, with **Read + write** if you publish. See [`scope_mismatch_repo`](/docs/reference/error-codes.html#scope_mismatch_repo). | | `404 Not Found` | Nothing is served at that address for your credential. The repository may be a proxy the token does not reach (CloudRepo answers `404`, not `403`, for that). With npm, a token that is mistyped, expired, revoked or from another organization also answers `404`. | Check the path against the repository’s **Connection Settings**, then the token. | | `409 Conflict` | Overwrite Protection refused to replace a version that already exists. | Publish a new version. See [Maven](/docs/formats/maven.html#maven-overwrite-protection) and [Python](/docs/formats/python.html#overwrite-protection). | | `413 Request Entity Too Large` | The file is over the format’s size limit: 50 GB per file in Maven, 210 MB per package in npm. | See [Maven Repositories](/docs/formats/maven.html) and [npm Repositories](/docs/formats/npm.html#package-size-limit). | | `5xx`, or no answer | Not your credential. | Check [status.cloudrepo.io](https://status.cloudrepo.io), then [contact support](/docs/reference/support.html). | ## Test the credential on its own A build tool can hide the answer behind its own message. `curl` shows the status plainly. This test is for Maven, Python and npm repositories. For Docker, run `docker login your-org.mycloudrepo.io`, which reports for itself whether CloudRepo accepted the credential: a request to the bare host checks no credential, so whatever it answers tells you nothing about your token. Keep your token out of the command line by putting it in `~/.netrc`, which curl reads with `--netrc`: `~/.netrc` ```ini machine your-org.mycloudrepo.io login you@example.com password YOUR_REPOSITORY_TOKEN ``` Keep the file readable by you alone (`chmod 600 ~/.netrc`), and use the address your repository’s **Connection Settings** show: **Terminal** ```bash curl --netrc --silent --output /dev/null --write-out '%{http_code}\n' \ https://your-org.mycloudrepo.io/repositories/your-repo/ ``` - `401`: CloudRepo refused the credential, or does not serve that address. Check the username is the email address of the account that created the token, that the token has not expired or been revoked on the **Repository Tokens** page, and that the address is exactly the one in **Connection Settings**. - `403`: the credential is good, but it may not do this. See the table above. - `404`: this alone does not say the credential is bad. A Maven repository you publish to, with nothing published in it yet, answers `404` at its root even with a good credential. The table above lists the other causes. - `200`: the credential works. If your build still fails, the difference is in how the build sends it. CloudRepo answers `401` for any address it does not serve, so a wrong address can look like a bad credential. Test against the repository’s own address, never a made-up path: it will answer `401` whether your credential is good or not. ## Check the address A wrong address can answer `401` or `404`. Each format has one shape: - **Maven, npm, Python:** `https://your-org.mycloudrepo.io/repositories/your-repo`. A path without `/repositories/` is an address CloudRepo does not serve. - **pip:** the index URL ends with `/simple/`, `https://your-org.mycloudrepo.io/repositories/your-repo/simple/`. twine uploads to the repository address without `/simple/`. - **npm:** the registry URL ends with `/`, and the `_authToken` line repeats it without `https:`. See [Repository Tokens](/docs/authenticate/repository-tokens.html). - **Docker:** `docker login` takes the host alone, `your-org.mycloudrepo.io`. The image reference adds `repositories/`, then the repository: `your-org.mycloudrepo.io/repositories/your-repo/my-app:1.0.0`. ## Read your client’s debug output safely A tool’s verbose mode shows what it sent and what CloudRepo answered. These are each tool’s own flags: **Terminal** ```bash mvn -X deploy gradle --debug publish npm publish --loglevel verbose pip install -v my-package curl -v --netrc https://your-org.mycloudrepo.io/repositories/your-repo/ ``` **A debug log can hold your token.** Measured on 2026-10-06 against a stub that accepted any credential: - `mvn -X` prints every environment variable with its value, so a token you pass as `CLOUDREPO_TOKEN` appears in the log. - `curl -v` prints the `Authorization` header. For Basic authentication that is your email address and your token, base64 encoded, which anyone can decode. Before you share a log with anyone, including in an issue, a chat or an email to support, search it for your token and for `Authorization`, and remove what you find. If a token has been in a log you shared, revoke it on the **Repository Tokens** page and create a new one. ## Certificate errors If your network inspects TLS, the certificate your tool sees is your proxy’s, not CloudRepo’s. Add your proxy’s certificate authority to the tool’s trust store, as your tool’s documentation describes, and do not turn certificate verification off. ## Still stuck [Contact support](/docs/reference/support.html) with the details it lists. The [error codes](/docs/reference/error-codes.html) page explains the codes documented so far, and [Repository Tokens](/docs/authenticate/repository-tokens.html) has the credential checks for every client. --- The page: https://www.cloudrepo.io/docs/reference/troubleshooting.html