Checking state and finding faults

Most of the time spent debugging goes on looking in the wrong place. So it is worth asking one question first: what changed most recently? In almost every case the problem is there, and not where the symptom appears.

Four questions, in this order

Did the change arrive at all? The portal shows whether your last commit was applied or whether applying it failed. If it failed, nothing about the runtime changed, and you are currently hunting a bug in a version that is not running.

Is the application running? Arrived is not the same as started. A container that crashes on startup is retried over and over. Your application's state in the portal tells you whether it is ready; the logs tell you why it is not.

Is it reachable? If the application runs and still nothing answers, this is about the route, not the application any more. Networking and reachability covers the common cases.

Is a rule blocking something? When an action is not permitted at all, the portal names the reason. That is not a fault but a boundary of your account, and the way past it is a request.

What it almost always turns out to be

A handful of patterns come up often enough to rule out first.

The namespace in the manifest does not match the one from the portal. The volume exists, but no manifest references it. A secret is referenced under a name that does not exist. The image tag points at a version that is not in the registry. The service finds no matching pods because the labels do not line up.

What to send support

The faster we see what you see, the faster it is over. Useful: the organisation and application concerned, the namespace, what you changed last, the exact error message, when it happened, and whether anything in production is affected.

Do not send passwords, tokens, private keys, or whole environment files. If a credential is part of the problem, say so and we will tell you where to put it.