01
Read the revision’s earliest application error
Identify the failing revision and compare its logs with the previous working revision. If the process crashes during import or exits because a required setting is absent, it never reaches a listening socket. Correcting that error comes before changing port configuration.
Cloud Run captures container stdout and stderr alongside platform logs. Correlate messages by revision and instance where possible so concurrent starts do not look like one sequence. Record the deployed image digest; a reused tag alone is not a reliable comparison of what ran.
02
Check the ingress container’s address and port
A Cloud Run service’s ingress container must listen on 0.0.0.0 and the configured request port. Cloud Run supplies PORT to that container; the usual default request port is 8080, but the service can be configured differently. Binding only to 127.0.0.1 does not satisfy the ingress contract.
Check the application code or framework configuration, not only the Dockerfile. EXPOSE does not create a listener. A development server that picks a hardcoded port can pass on a laptop while failing when deployed with a different configured PORT.
03
Use an explicit listener in a minimal comparison
This Node.js example reads PORT and binds all interfaces. It is a small contract check, not a production web framework. It helps distinguish the network-listening requirement from the rest of an application’s initialization.
Validate the value instead of silently accepting an invalid configuration. If your real application already has a framework-managed listener, configure that listener rather than adding a second competing server. Save this as server.mjs and run it with Node.
import http from 'node:http';
const port = Number(process.env.PORT ?? 8080);
if (!Number.isInteger(port) || port < 1 || port > 65535) {
throw new Error('PORT must be an integer from 1 to 65535');
}
http.createServer((_request, response) => {
response.writeHead(200, { 'content-type': 'text/plain' });
response.end('listener ready\n');
}).listen(port, '0.0.0.0', () => {
console.log(`Listening on 0.0.0.0:${port}`);
});04
Test a nondefault port in the same image
Run your built image locally with an explicit nondefault PORT and a matching mapping. This catches a listener that accidentally works only with a hardcoded default. The example below uses port 9090 inside the container and 19090 on your host.
If the image needs secrets or cloud services, use a safe test configuration. Do not copy production credentials into a debugging image. Confirm that the image starts the intended long-running process and is built for a platform Cloud Run supports; architecture and entrypoint failures are distinct from port mismatches.
# Runs a disposable copy of your own built image.
docker run --rm -e PORT=9090 -p 127.0.0.1:19090:9090 example-api:tested
# In another terminal:
curl --fail --max-time 5 http://127.0.0.1:19090/05
Do not use more startup time to hide a deterministic failure
A slow but valid initialization can justify reviewing startup-probe timing. A process that binds the wrong address or crashes on every start will not become correct by waiting longer. First identify which case the logs and local comparison support.
Likewise, increasing an HTTP request timeout does not make an absent startup listener appear. Keep request execution budgets, startup health, and application readiness as separate questions. Change one setting at a time so the resulting evidence remains interpretable.
06
Verify readiness and the actual application operation
Deploy through the normal revision workflow and check that the new revision becomes ready. Then test the service URL using the appropriate authentication for the service. A startup contract check and a successful authorized business request are different acceptance checks.
Retest a cold start in a controlled environment when feasible. Keep the original startup error, the corrected listen configuration, the deployed revision identity, and the request result. If the error persists with a matching listener, return to the earliest process error rather than cycling through unrelated Cloud Run settings.
Sınırları bil
This applies to Cloud Run services with an HTTP ingress container. Cloud Run jobs have a different execution contract. The minimal server demonstrates listening behavior and does not implement authentication or production health semantics.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet