When something is wrong
The handful of failures that account for most of them, what each looks like, and what to do.
On this page
Start here
klickops tries to say what is wrong in one sentence on the workload itself, so read the status line before anything else. Then the Logs tab, which is where the container's own account of its death lives.
Three questions answer most of it. Did it ever start? Did it start and then stop? Or is it running and simply not reachable? Those are different problems and the sections below follow that order.
It never starts
The image cannot be pulled. The name is wrong, the tag does not exist, or the registry needs credentials klickops does not have. Check the exact reference, and for a private registry check that it has pull credentials. A typo in a tag looks identical to a missing image.
It is blocked by the project quota. The status says so directly: there is not enough CPU or memory left in the project to start it. Either remove a workload or raise the project quota. A database refused this way sits at a provisioning phase forever, because the operator never gets a pod to report on.
The plan limit refused it. This one fails at create time with a message naming the limit, so it is visible immediately rather than as a stall. See Plans and costs.
It starts and then stops
It exits cleanly. klickops restarts it, because an app is expected to stay up. If the thing genuinely should run once and finish, it is a scheduled job, not an app.
It crashes on start. The logs of the failed attempt hold the reason, and it is usually one of three things: a missing environment variable, a database it cannot reach yet, or a port mismatch. Check that the port you configured is the port the process actually listens on.
It runs out of memory. The container is killed and restarted, with a restart count that keeps climbing. Memory is auto-sized to actual usage, so a process that genuinely needs more will get more, but a leak will simply be killed repeatedly.
A failed rollout does not take the running version with it. klickops waits for the new copies to pass their health check before retiring the old ones, so a broken image leaves the previous version serving. The app looks unhealthy while it retries, and your users do not notice.
It runs but is not reachable
Check the health check first. Traffic is withheld until the port accepts a connection. A process that listens on a different port than the one configured is healthy from your side and invisible from the outside.
Then DNS. If the hostname does not resolve, the certificate was never issued and the domain check never went green. See Domains.
Then the firewall. A blocked connection times out rather than being refused, so it looks like slowness, not like a denial. The Flows view shows denied traffic explicitly, which is faster than guessing. See Firewall.
A database is stuck provisioning
Give it two minutes: a PostgreSQL cluster genuinely takes that long to bootstrap. Past that, the usual cause is the project quota, described above.
If it reports healthy but your app cannot connect, the problem is almost never the database. Check that the app has the binding, and that both are in the same project, because nothing crosses a project boundary without a firewall rule.
When to ask
When you have the workload name, the time it started failing, and the exact message. Those three turn a conversation into an answer.
Related
- Backups and recovery when the fix is to go back rather than forward.
- Apps for what each tab shows.