Troubleshooting Intake
The release page lists the failed check under Errors and messages, with a message saying what went wrong. Find that check below, then look for your message.
A few are problems on the Armada side, and editing your chart will not clear them. Every entry says who fixes it — where it says Armada, report it rather than spending an afternoon on something you cannot change.
Before a run even starts
| What you see | What it means | What to do |
|---|---|---|
| No App management tab | Your account is not set up for publishing | See Check you can publish. Someone at Armada has to turn it on |
Metadata Validation
| Message | What it means | What to do |
|---|---|---|
| Invalid version | Your Bundle version is not a valid version number — it must be three numbers separated by dots, like 1.0.2 | Correct it and submit again |
| Required field missing | Something required is empty. The message says which | Fill it in. Your chart needs a repository, a chart name, and a tag or digest |
Helm Chart Validation
| Message | What it means | What to do |
|---|---|---|
| Lint error | Your chart has a formatting problem | Run helm lint ./mychart — you will see exactly the same complaint |
| Template rendering failed | Your chart will not build. Usually a missing value or a typo in a template | Run helm template ./mychart with the same values |
| Template validation failed | Your chart builds, but the result is not something Kubernetes accepts | Run helm template ./mychart | kubectl apply --dry-run=client -f - |
| Chart version mismatch | The chart version you submitted is not character-for-character the version inside your Chart.yaml — a leading v is enough to break it | Make the two identical. This is the chart version, not the Bundle version |
| Invalid chart metadata | Your Chart.yaml is malformed or missing something required | A chart needs Chart.yaml, values.yaml, and a templates folder |
| Chart fetch failed | The chart could not be downloaded from the repository you gave | Check the address and the credentials. Try once more before reporting it |
| No images found | Your chart does not ask for any container images, so there would be nothing to install | Usually a chart whose default settings switch everything off, or one that only carries configuration. Check that the defaults actually start your application |
Secret Validation
The most common reason a first submission fails, even though it runs third.
The platform checks your secrets are there; it does not create them. Set them up in the release form, and give a new registry vault its full two minutes before submitting.
| Message | What it means | What to do |
|---|---|---|
| Secret not found in vault | Your chart asks for a secret that is not in the vault | Add it, then submit the release again. Check the spelling — hyphens are allowed, underscores are not |
| Application vault not found | Your chart names a vault that does not exist | Create it, or correct the name in your chart. Remember vault names are shared across all customers, so the name you wanted may already be taken |
| Internal server error | A fault on the Armada side, not something in your chart | Report it — see Failures on the Armada side. Do not change your chart |
Two things, in this order.
Did the secret go into the same vault your chart names? Another of your vaults will not do.
Does the name match exactly? A hyphen where your chart has an underscore is the usual culprit — and underscores are not valid in secret names at all, so if your chart uses one, that is your answer.
Images Validation
| Message | What it means | What to do |
|---|---|---|
| Image pull failed | One of the images your chart needs could not be downloaded | Check that the tag still exists and has not been deleted or overwritten, and that your credentials can read that repository. Every image is checked, so one bad tag fails the whole check |
| Credential fetch failed | Your registry credentials could not be retrieved | Check that a registry vault exists for that registry address, and that the registry type you picked matches the registry you actually use |
Test Application Deploy
Your chart passed every check; your application did not start. These point at the application and its settings, not your packaging.
| What the deployment did | What it means |
|---|---|
| The container kept restarting | It starts, then stops, over and over. Usually a wrong start command, a missing setting, or something it depends on not being there |
| The image would not download | The cluster could not fetch your image, even though the earlier check passed. Usually about credentials reaching the cluster |
| The image name was not valid | The image address is malformed |
| A setting it needed was missing | Your application refers to a configuration or secret that is not there |
| It ran out of memory | Your application asked for more memory than its limit allowed, so it was stopped |
| It would not fit on any machine | No machine had enough room for it as specified |
Running out of memory and not fitting stop your release — they are not warnings to revisit later.
An edge site runs on a fixed set of hardware, so capacity does not scale out on demand the way it does in the cloud. Set your memory and CPU requests to what your application actually needs, and test against the limits of the hardware you are targeting before submitting. See Container Best Practices.
Submitting and cancelling
These are not check failures — they are the platform refusing an action.
| Message | What it means | What to do |
|---|---|---|
| Intake already in progress | A run is already going for this application and version | Wait for it, or cancel it. Do not submit again — that is what caused this |
| Invalid release state | The action does not apply to the release as it stands | Check where your release is in its life |
| Cannot be cancelled | The run has already finished | Nothing — let it be |
| Not found | The application, release, or run does not exist | Usually an old or mistyped reference |
Armada Review
Being turned down is not failing a check — every automated check passed and a person decided against the release.
Their reason appears under Errors and messages on the release page. Read it, address it, then submit the same release again.
Failures on the Armada side
Report these. Do not change anything:
| Message | What it means |
|---|---|
| Artifact staging failed | Your chart could not be fetched for checking |
| Upstream dependency failed | Something the platform relies on failed. Trying again may work |
| Internal server error | A fault on the Armada side |
Submitting again after a failure
A failed or rejected release stays editable, so you retry on the same release — there is no need for a new Bundle version.
- Fix what went wrong. Everything is still editable: the chart, the registry details, the version, the release notes.
- Check
Chart.yaml'sversionstill matches the chart version you are submitting — that pairing is separate from the Bundle version. - Submit for review again. The checks start from the beginning; nothing is skipped or remembered.
You only need a new Bundle version for a genuinely new version of your application. Versions are unique per application, so once one has been published you cannot reuse its number.
Asking for help
Bring these four things, or the first reply will just be a request for them:
- The run reference
- Your application name and version
- Which check failed
- The message shown against it, copied exactly