Getting a timeout error when I try accessing an MCP server deployed on cloud run

Google Cloud Serverless Applications
1

Hi all, I have dockerized & deployed an MCP server to cloud run with port 8080 exposed. When I try accessing the server in an MCP client, I get a timeout error. When I check cloud run logs, I see this “Truncated response body. Usually implies that the request timed out or the application exited before the response was finished.“

Though the dockerized MCP server is working fine locally when I test it. It’s weird seeing it get a timeout error in cloud run.

I have used the following resources in the cloud run service;

  • Memory of 4GiB and 2 vCPU.
  • I have set the request timeout to 800
  • I have set the Minimum number of instances to 1.

The following resources should be more than enough, I really don’t know why that’s happening and I’m thinking this is most likely a cloud run issue. Please help.

2

Hi Kamal_Moha,

Based on the latest Google Cloud Service Health Dashboard for Cloud Run, there are no incident reports listed for the last 2 weeks. The last incident was on July 18, 2025, with elevated error rates across multiple products in us-east1.

Here are some suggestions that may help resolve the issue:

  • Timeout error is a common challenge when deploying an MCP server, which is a long-lived connection, to a serverless deployment like Cloud Run, which generally aren’t designed around long-lived requests. It may indicate how the MCP client handles the authentication redirect. If you’re using streamable HTTP transport, deploy your service with the --no-allow-unauthenticated and MCP client that runs on a local machine, try to authenticate the MCP client using gcloud run services proxy to establish a local proxy. As also described in this documentation. You might also find this relevant Github discussion helpful.

  • If possible, try increasing the request timeout as part of your troubleshooting. This is just to validate that the possible reason is that your service is processing a long request, which doesn’t respond within the specified request timeout, or the client disconnects before the response is completed.

  • Even with min-instances=1, you may still experience significant latency, which could result in startup delays. Consider enabling startup CPU boost to reduce startup latency. Additionally, you can refer to this documentation for best practices on designing, implementing, testing, and deploying a Cloud Run service, which includes other methods to reduce startup latency.

3

Hi @marckevin,

Thanks for the guidance on this. I have implemented the suggestions you’ve provided;

  • Yes, I’m using the streamable HTTP transport and developing this server using fastmcp. My cloud run service was initially exposed to the public and didn’t require any authentication. I have now implemented the authentication you suggested an then established a proxy by running gcloud run services proxy mcp-server --region=us-central1. But even when I used the proxy url to access the MCP server via the client, I get the same timeout error.
  • I increased the request timeout from 300 to 2400, but still go the issue of timeout error.
  • I set the min-instances=4 and enabled startup CPU boost. But continuing to get the same timeout error

@marckevin I’m curious to know, could it be that cloud run is not the best platform to deploy MCP servers?