Google API Gateway Buffering Your SSE Response? Enable Streaming on a New Gateway

On its own, the Cloud Run function streams, but through API Gateway the reply arrives all at once. After you turn on streaming, why does it stop at 15 seconds?

Google API Gateway Buffering Your SSE Response? Enable Streaming on a New Gateway
TLDR
  • Streaming is in public preview and can be enabled when creating a gateway.
  • SSE still has a 15-second default request deadline; enabling streaming does not grant an hour automatically.
  • Backend timeouts and client output buffering need separate checks.

The old “API Gateway cannot stream” answer has changed

A developer forum question describes the familiar split: a Cloud Run function streams directly, but API Gateway holds the response until it is complete. Google's September 29 release notes now list streaming in public preview. An October 22 developer announcement explains the feature in more detail.

Streaming mode is fixed at gateway creation. For an existing SSE backend, create a new gateway using your API and configuration IDs:

gcloud api-gateway gateways create GATEWAY_ID \
  --api=API_ID \
  --api-config=CONFIG_ID \
  --location=REGION \
  --enable-streaming

The creation command accepts the streaming flag. You do not need a new streaming-specific OpenAPI extension, but a configuration with a short backend deadline still needs adjustment.

Streaming output does not reset the SSE deadline

For SSE and chunked responses, the request deadline covers the entire response, including time spent sending data. The CLI reference specifies a default of 15 seconds and a maximum of 3,600 seconds on streaming gateways.

This OpenAPI 2.0 fragment follows the configuration guide. Replace the backend address; 3,600 is the maximum, not a required setting for every endpoint.

x-google-backend:
  address: https://YOUR_SERVICE.run.app
  protocol: h2
  deadline: 3600.0

The backend has its own clock. Cloud Run defaults to 300 seconds, so raising only the gateway deadline still leaves a five-minute cutoff. Application frameworks and clients may impose shorter timeouts too.

Inspect the gateway, then remove client output buffering

Describe the new gateway and check for effectiveStreamingMode: EFFECTIVE_STREAMING_MODE_ENABLED. Use its returned defaultHostname for requests.

gcloud api-gateway gateways describe GATEWAY_ID \
  --location=REGION

For a command-line comparison, add -N to curl while preserving the request's authentication headers and body. Compare direct backend delivery with gateway delivery. The flag disables curl's output buffer; it cannot change server-side buffering.

The 32 MB response limit does not apply to streamed or chunked responses. The request limit remains 32 MB, so a longer generated answer does not imply a larger upload allowance.

A custom-domain deployment needs extra planning

During the current preview, streaming gateways cannot sit behind Serverless NEGs or an external Application Load Balancer. Custom domains using that path are consequently unavailable. Terraform enablement is also unsupported.

Test delivery and timeouts through the new gateway hostname before moving clients. Reconnection remains an application concern: Cloud Run treats a reconnect as a new request, so the application must decide whether to resume previous output or generate a new response.