Cloud Run Instance stop: Are managed sandbox processes and resources guaranteed to terminate?

Google Cloud Serverless Applications
1

Hello,

I am evaluating Cloud Run for a non-production workload that uses FFmpeg inside a managed sandbox to process a short, synthetic audio file.

My main concern is whether sandbox processes and resources are reliably terminated when the parent Cloud Run runtime stops, especially if the parent application crashes or becomes unresponsive.

I am comparing Cloud Run Services with manually managed Cloud Run Instances. I understand that stopping or deleting a Cloud Run Instance is not the same as invoking an API to delete an individual sandbox.

I would appreciate clarification on the following questions.

1. Sandbox termination guarantees

When a Cloud Run Instance stop operation completes successfully, does Google Cloud guarantee that all managed sandbox processes and descendants associated with that instance have terminated, and that their namespaces, cgroups, mounts, and temporary storage resources have been released?

Does the same guarantee apply if the parent application crashes, encounters an out-of-memory condition, or the instance transitions to FAILED with restartPolicy=NEVER?

2. External verification

If the parent runtime is no longer accessible, which documented API fields, instance conditions, or operation results can an external controller use to determine that the sandbox and its resources have been terminated?

Is successful completion of the stop operation sufficient, or is additional verification required?

3. Time-bound termination

For our experimental safety requirements, we are evaluating termination within 5 seconds of a stop request, followed by 10 seconds of independent observation for residual processes or resources.

Is such a guarantee supported by the Cloud Run platform contract? If not, what termination guarantees or documented limits are available?

We are not requesting access to internal infrastructure. We are trying to identify which lifecycle guarantees can be relied upon through public APIs and which conditions must be validated separately.

References to official documentation would be especially helpful.

Thank you for your guidance.

2

You are right to separate the two things: stopping/deleting a Cloud Run Instance is not the same as calling an API to delete an individual sandbox, and the platform contract is different for the two shapes.

1. What a successful `stop` operation does mean: it means the instance’s lifecycle reached a terminal state in the Instances API — the instance is stopped and will not serve further requests. What it does not document is a guarantee that every process and descendant inside the container has been individually reaped, or that namespaces, cgroups, mounts and temporary storage were all released at that exact moment. In practice, stopping the instance tears down the sandbox that the processes live in, so they cannot keep running as part of that instance — but that is the effect of tearing down the whole sandbox, not a documented per-process guarantee, and it is not a proof you can hand to an auditor.

The same applies when the parent crashes or the container is OOM-killed, and also to `restartPolicy=NEVER` with a terminal `FAILED` state: the terminal state is about the instance/job lifecycle, not about an individual process tree. A crashed or unresponsive PID 1 that has not reaped its children is exactly the case the platform does not certify — that is why the container’s init matters (a real init as PID 1, or an entrypoint that forwards SIGTERM and `wait()`s for its children, with FFmpeg as a tracked child whose exit code/signal is logged).

2. External verification, after the parent is gone: the documented, provider-origin fields are the instance/execution lifecycle state. For Instances, that is `gcloud run instances get --region=` / the Instances API resource state and the long-running operation returned by `stop` (`operations.get` until the operation reports done — a `done` operation with no error means the stop itself completed, not that a process tree was inspected). Cloud Logging entries for that instance and Cloud Audit Logs for the instance lifecycle are the durable records; application logs are not, because they stop when the container does. Successful completion of the `stop` operation is the verification that the instance is stopped. It is not, on its own, additional verification that zero processes survived — there is no API field that says that.

3. Time bound: no, a 5-second guarantee is not supported by the Cloud Run platform contract, and I would not put it in a safety case. The docs describe a graceful termination period for services (SIGTERM, then a grace period before SIGKILL — 10 seconds by default for Cloud Run services), but that is a container lifecycle behaviour, not a wall-clock SLA for sandbox teardown, and it does not cover host or control-plane failure. For a manually managed instance, the same point holds: there is no published upper bound for instance stop completing. If your experiment needs termination certified within 5 seconds, you need to measure it yourself under your own workload and treat that as an observed behaviour, not a platform guarantee — or use a primitive that tracks process lifetimes itself.

Practical takeaway for the FFmpeg workload: keep the sandbox question inside the container (real init, tracked child, SIGTERM handling, exit-status logging, idempotent output so a killed run cannot leave a half-finished file), and use the Instances API state + operation completion + audit logs as your external evidence that the instance stopped. Do not rely on the stop operation to prove that the process tree was reaped.

3

Hi Benjamin,

Thank you very much for your detailed and thoughtful explanation.

Your clarification about the difference between instance lifecycle termination and process-level termination guarantees was extremely helpful.

It helped us better understand the limitations of Cloud Run and make a more informed decision about our FFmpeg safety architecture.

We are now exploring an alternative approach that avoids server-side FFmpeg processing altogether.

Thank you again for taking the time to help us!

Best regards,
yuji