Skip to main content
Supported Regions:上海

Deployment Failure Related

Local runs normally, but deployment fails after deploying to Cloud Run?​

Local debugging should be based on local Docker as much as possible. If local development and debugging is not based on Docker, and you directly deploy to Cloud Run, you may encounter the following situations:

  • When running locally, various dependency components and extensions are complete locally, but dependency installation commands are not correctly added to the Dockerfile. So there are no missing dependencies when running locally, but errors will occur due to lack of dependencies when deploying to Cloud Run.
  • When running locally, it connects to the local database (address is local IP or localhost). When deploying to Cloud Run, the database address is not changed to the cloud database address, causing deployment failure due to inability to connect to the database.
  • The runtime environment used locally (JDK/python version, etc.) is inconsistent with the runtime environment defined in the Dockerfile.

How to handle the error message "Readiness probe failed: dial tcp xx.xx.xx.xx:xxx: connect: connection refused"?​

Unable to pass health check/port call fails.

  • The service starts normally, but the port is filled incorrectly. The real port does not match the port filled when publishing, causing the system to mistakenly think the deployment failed.
  • The service starts normally, but does not listen to any local port of 0.0.0.0, causing the system to think the deployment failed.
  • The service starts successfully, but restarts repeatedly with unstable processes, causing the port to be unable to connect stably and unable to pass health checks. Please troubleshoot code issues by combining logs, or consider whether it is caused by OOM due to the selected container specification being too small.
  • If your Dockerfile contains multiple independent CMD commands, please note that this is incorrect syntax. Only the last CMD command will be executed, and the previous ones will be ignored, causing business errors. Please refer to the Docker official documentation for CMD commands.
  • Check whether the port exposed in the Dockerfile is inconsistent with the port configured for the service.

You can use commands like netstat during local debugging to check whether the locally listened port is consistent with the Cloud Run configured port.

Deployment fails but business logs show normal operation?​

Check whether the port in service settings is consistent with the actual project port. If the service starts normally, but the port is filled incorrectly, and the real port does not match the port filled when publishing, it will cause the system to mistakenly think the deployment failed, and calling the service will also report errors.

How to handle the error message "check pod status is not ok"?​

Please first check the following information:

  • The service restarts repeatedly due to code reasons, with unstable status. Please troubleshoot code issues yourself.
  • If the service does not restart repeatedly, please submit a ticket to contact us for troubleshooting.

How to handle the error message "Back-off restarting failed container"?​

Service startup failure caused by code reasons. Please use service logs to troubleshoot code issues yourself. If no service logs are collected, please check whether the log collection path of the service is configured correctly.

Why does deploying eggjs service and running npm run start keep restarting repeatedly?​

Need to remove the process daemon parameter --daemon.

  • Before change: "start": "egg-scripts start --daemon --title=node-server",
  • After change: "start": "egg-scripts start --title=node-server"

Why don't environment variables referenced in Dockerfile take effect?​

During the build or deployment phase, the service is not ready yet, so environment variables cannot be referenced at this time.

Environment variables referenced in Dockerfile for MySQL/Redis and other cloud products' internal network addresses don't take effect?​

During the build/deployment phase, the service is not ready yet, so other cloud products cannot be accessed through internal network addresses at this time.

How to handle the error message "err=[ResourceUnavailable.ClusterInAbnormalState][err=cloudrun cluster state is invalid(cluster state is deleted)]"?​

Underlying exception, please submit a ticket to contact us for processing.

Does the mini-program embedded webview method support Cloud Run internal network address calls?​

Not supported. The client internal network of mini-programs and the server internal network of Cloud Run are not in the same network space and cannot call each other.

Pipeline executes normally, but service cannot start. How to troubleshoot yourself?​

  • Check whether there are obvious errors in service startup logs
  • Customers can use docker deployment locally to verify whether there are problems with program startup

Accessing service reports error CERTIFICATE_VERIFY_FAILED​

Refer to Usage Notes, customers need to trust certificates in their service Dockerfile and customer code

Local listening on 127.0.0.1:80 service is normal, but cannot start when deployed to Cloud Run​

Modify to 0.0.0.0:80 listening port, then redeploy the service.

Image-based deployment, service startup error "exec /bin/sh: exec format error"​

  • Cloud Run containers only support amd images. If it's an arm image, this error will occur. You can build amd images yourself or choose open-source amd type images
  • Customers can check the image type through docker inspect "image repository address" | grep Architecture

Service deployment startup error " xxxx recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0"​

  • The service is compiled using Java 17 (version 61.0), but you are trying to run it using Java 8 (version 52.0) environment. Lower version Java runtime cannot load class files generated by higher version Java compiler
  • You can check that the Java version in Dockerfile should be consistent with the Java version in pom.xml in the service code

CLI deployment Cloud Run call failure "Error: cloud.callContainer:fail Error: errCode: -501000 | errMsg: Your server is Forbidden For CallContainer."​