Stay organized with collections
Save and categorize content based on your preferences.
After you create a cluster, you can stop it, then restart it when you need
it. Stopping an idle cluster avoids incurring charges
and avoids the need to delete an idle cluster, then create a cluster with the
same configuration later.
Notes:
The cluster start and stop feature is available on clusters created with
images released on or after the following image versions:
1.4.35-debian10/ubuntu18
1.5.10-debian10/ubuntu18
2.0.0-RC6-debian10/ubuntu18
Stopping individual cluster nodes is not recommended since the status of
a stopped VM may not be in sync with cluster status, which can result in
errors.
Stopping a cluster
Stopping a cluster stops all cluster Compute Engine VMs. You don't
pay for VMs while they are stopped. However, you continue to pay for
any associated cluster resources, such as
persistent disks.
Notes:
Running operations: If a cluster has running operations,
such as update or diagnose operations, the stop request will fail.
Running jobs: If a cluster has running jobs, the stop request will
succeed: the VMs will stop, and the running jobs will fail.
Stop Response: When the stop request returns a stop operation,
the cluster will be in a STOPPING state, and no further jobs will be allowed
to be submitted (SubmitJob requests will fail).
Autoscaling: If you stop a cluster that has
autoscaling enabled,
the Dataproc autoscaler will stop scaling the cluster. It will
resume scaling the cluster once the cluster is restarted. If you enable
autoscaling on a stopped cluster, the autoscaling policy will take effect
once the cluster has been restarted.
When you restart a stopped cluster, any initialization actions won't be re-run.
Initialization actions only run on cluster nodes when the cluster is
created or when nodes are added when the cluster is scaled up.
After the start operation completes, you can immediately submit jobs to the
cluster. However, execution of the jobs can be delayedโapproximately
30 secondsโto allow HDFS and YARN to become operational.
How to stop and start a cluster
You can stop and start a cluster using the Google Cloud console,
gcloud CLI, or the Dataproc API.
Google Cloud console
Click the cluster name from the Dataproc
Clusters page in the
Google Cloud console, then click STOP to stop and START to start the cluster.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-01 UTC."],[[["\u003cp\u003eYou can stop a Dataproc cluster to avoid charges when it's idle, and then restart it when needed, eliminating the need to delete and recreate clusters.\u003c/p\u003e\n"],["\u003cp\u003eStopping a cluster halts all Compute Engine VMs, preventing VM charges, but you'll still pay for associated resources like persistent disks.\u003c/p\u003e\n"],["\u003cp\u003eThe stop request will fail if a cluster has running operations and any jobs will also fail if they are running when the cluster stops.\u003c/p\u003e\n"],["\u003cp\u003eAfter a cluster is stopped, you cannot update the cluster, submit jobs, or access notebooks, and there are limitations on which clusters can be stopped, including those with secondary workers or local SSDs.\u003c/p\u003e\n"],["\u003cp\u003eWhen starting a stopped cluster, initialization actions are not rerun, and although jobs can be submitted immediately, their execution may be delayed briefly for HDFS and YARN to become operational.\u003c/p\u003e\n"]]],[],null,["After you create a cluster, you can stop it, then restart it when you need\nit. Stopping an idle cluster avoids incurring charges\nand avoids the need to delete an idle cluster, then create a cluster with the\nsame configuration later.\n\nNotes:\n\n- The cluster start and stop feature is available on clusters created with images released on or after the following image versions:\n - 1.4.35-debian10/ubuntu18\n - 1.5.10-debian10/ubuntu18\n - 2.0.0-RC6-debian10/ubuntu18\n- Stopping individual cluster nodes is not recommended since the status of a stopped VM may not be in sync with cluster status, which can result in errors.\n\n| **Note:** To schedule stopping a cluster, see [Cluster scheduled stop](/dataproc/docs/concepts/configuring-clusters/scheduled-stop).\n\nStopping a cluster\n\nStopping a cluster stops all cluster Compute Engine VMs. You don't\npay for VMs while they are stopped. However, you continue to pay for\nany associated cluster resources, such as\n[persistent disks](/dataproc/docs/concepts/compute/dataproc-persistent-disks).\n\nNotes:\n\n- **Running operations:** If a cluster has running operations, such as update or diagnose operations, the stop request will fail.\n- **Running jobs:** If a cluster has running jobs, the stop request will succeed: the VMs will stop, and the running jobs will fail.\n- **Stop Response:** When the stop request returns a stop operation, the cluster will be in a `STOPPING` state, and no further jobs will be allowed to be submitted (`SubmitJob` requests will fail).\n- **Autoscaling:** If you stop a cluster that has [autoscaling](/dataproc/docs/concepts/configuring-clusters/autoscaling) enabled, the Dataproc autoscaler will stop scaling the cluster. It will resume scaling the cluster once the cluster is restarted. If you enable autoscaling on a stopped cluster, the autoscaling policy will take effect once the cluster has been restarted.\n\nMonitoring the stop operation\n\nYou can run\n[`gcloud dataproc operations describe `\u003cvar translate=\"no\"\u003eoperation-id\u003c/var\u003e](/sdk/gcloud/reference/dataproc/operations/describe)\nto monitor the long-running cluster stop operation. You can use the\n[`gcloud dataproc clusters describe `\u003cvar translate=\"no\"\u003ecluster-name\u003c/var\u003e](/sdk/gcloud/reference/dataproc/clusters/describe)\ncommand to monitor the transitioning of the cluster's status from\n`RUNNING` to `STOPPING` to `STOPPED`.\n\nLimitations\n\n- You cannot stop:\n\n - clusters with [secondary workers](/dataproc/docs/concepts/compute/secondary-vms)\n - clusters with [local ssds](/dataproc/docs/concepts/compute/dataproc-local-ssds)\n- After a cluster is stopped, you cannot:\n\n - update the cluster\n - submit jobs to the cluster\n - access notebooks running on the cluster using the [Dataproc component gateway](/dataproc/docs/concepts/accessing/dataproc-gateways)\n\nStarting a cluster\n\n- When you restart a stopped cluster, any initialization actions won't be re-run.\n Initialization actions only run on cluster nodes when the cluster is\n created or when nodes are added when the cluster is scaled up.\n\n- After the start operation completes, you can immediately submit jobs to the\n cluster. However, execution of the jobs can be delayed---approximately\n 30 seconds---to allow HDFS and YARN to become operational.\n\nHow to stop and start a cluster\n\nYou can stop and start a cluster using the Google Cloud console,\ngcloud CLI, or the Dataproc API. \n\nGoogle Cloud console\n\nClick the cluster name from the Dataproc\n[Clusters](https://console.cloud.google.com/dataproc/clusters) page in the\nGoogle Cloud console, then click STOP to stop and START to start the cluster.\n\ngcloud CLI\n\n**Stop a cluster** \n\n```\ngcloud dataproc clusters stop CLUSTER_NAME \\\n --region=REGION\n```\n\n**Start a cluster** \n\n```\ngcloud dataproc clusters start CLUSTER_NAME \\\n --region=REGION\n```\n\nREST API\n\n**Stop a cluster**\n\nSubmit a\n[clusters.stop](/dataproc/docs/reference/rest/v1/projects.regions.clusters/stop)\nrequest.\n\n**Start a cluster**\n\nSubmit a\n[clusters.start](/dataproc/docs/reference/rest/v1/projects.regions.clusters/start)\nrequest."]]
