Startup probe failing even not configured

Hi, azure container Apps will create a default startup probe when ingress is enabled, even if you didn’t configure one (the blade even says “a default probe may be created”). That probe tries to connect to your targetPort (TCP or HTTP on “/”); connection refused means your container isn’t accepting connections on that port yet/at all, so the platform restarts it. Fix it by matching one of these cases: if the app is a worker with no listener, set Ingress = Disabled (no probe, no restarts); if it does expose HTTP/gRPC, make sure it listens on 0.0.0.0:<targetPort> (not 127.0.0.1), the port matches the Ingress targetPort, and protocol matches (set transport=http2 for gRPC/h2c). Then add an explicit Startup probe tuned for your boot time (e.g., HTTP path /healthz that returns 200–399, or a TCP probe; give it a generous initialDelaySeconds and failureThreshold), and set proper Readiness/Liveness too—if / returns 401/redirect, the default HTTP probe will fail, so use an unauthenticated health endpoint. Quick checks: verify the container logs to see the app binding (az containerapp logs show -g <rg> -n <app> --type app --follow), inspect the effective probes (az containerapp show -g <rg> -n <app> --query "properties.template.containers[0].probes"), and, while debugging cold starts, consider minReplicas=1 or lengthen the probe thresholds.