Outbound connections fail
Your application cannot reach something outside the cluster. Nothing rejects the manifest and nothing appears in the logs beyond a timeout, which makes this harder to diagnose than it should be.
Check the tier first, because the answer is completely different.
On the free tier: only the web
A free namespace may open outbound connections on HTTP (80) and HTTPS (443) only, plus DNS. Everything else is dropped, silently, so the symptom is a hang followed by a timeout.
That means an external database, cache or message broker is unreachable. There is no way around it on this tier:
| Trying to reach | Works on the free tier? |
|---|---|
| An HTTPS API | Yes |
| A container registry | Yes |
| PostgreSQL on 5432, MySQL on 3306, Redis on 6379 | No |
| SMTP on any port | No |
| Anything else on a non-web port | No |
The fix is to run the dependency inside your own namespace, where pods reach each other freely, or move to a paid plan. See Free tier.
On paid plans: almost everything works
Outbound is open, with two exceptions.
Port 25 is blocked, on every tier. Sending mail by connecting directly to a recipient's mail server does not work. Use a mail provider's submission port or their HTTP API instead; on a paid plan 587 is not blocked, so most providers work unchanged, ITSH Email included. This is the single most common surprise on this page.
The cloud metadata address is unreachable. Libraries that try to auto-discover cloud credentials will hang against it and then fall back. If you see a startup delay of a few seconds in an SDK, this is usually why. Configure credentials explicitly rather than letting it probe.
Something inside the cluster is unreachable
Pods in the same namespace reach each other with no restrictions. Use the Service name:
kubectl run -it --rm check --image=busybox --restart=Never -- \
wget -qO- http://myapp:80/healthzAnother tenant's namespace is not reachable, by design, and neither is yours from theirs.
The Kubernetes API is reachable from inside a pod if your application needs it.
Confirming it is the network and not your app
Run a throwaway pod and try the connection by hand. If this hangs, the problem is not your application:
kubectl run -it --rm netcheck --image=busybox --restart=Never -- \
sh -c 'nc -zv -w 5 db.example.com 5432; wget -qO- -T 5 https://example.com >/dev/null && echo https-ok'On a free namespace the first will time out and the second will succeed, which is the signature of the allowlist rather than a broken host.