Unable to make Community edition cluster for multiple days

DeltaScratchpad — Tue, 10 Jun 2025 09:55:21 GMT

Hi,
I've been trying to use CE to learn the basics, but I have never been able to make a compute cluster to actually run any workloads / notebooks.

I have tried on 3 separate days now, and below I've attached the most recent attempt error log.

Since CE locks down all the config options, I don't expect there's any way I could have messed it up.

I tried the support contact page (REQ 00679712) but they told me to post here instead.

Err:

{ "reason": { "code": "CONTAINER_LAUNCH_FAILURE", "type": "SERVICE_FAULT", "parameters": { "instance_id": "i-04527fe35431957a8", "databricks_error_message": "Failed to launch spark container on instance i-04527fe35431957a8. Exception: Container setup has timed out" } } }

Re: Unable to make Community edition cluster for multiple days

Louis_Frolio — Mon, 03 Nov 2025 21:07:44 GMT

@DeltaScratchpad , thanks for sharing the details and the error payload — I know it’s frustrating to hit this repeatedly in Community Edition (CE).

What your error means

The CONTAINER_LAUNCH_FAILURE with “Container setup has timed out” means the dataplane VM came up, but the Spark container couldn’t finish its setup within the timeout window. This is typically transient and can be caused by a few well-known conditions:

Slow Spark image download or registry access, which consumes most of the launch window and then times out. Retrying later often succeeds once the transient condition clears.
Instance reuse/container name conflicts during container setup, which can block a new container from launching cleanly. Creating a fresh compute (new cluster) avoids reuse and often mitigates this pattern.
Cloud capacity or bootstrap/network hiccups on the provider side (e.g., delayed VM launch, networking/DNS issues), which can manifest as timeouts during bootstrap or container setup. These usually resolve on their own and are not caused by user configuration in CE.
Less commonly, regional networking anomalies or firewall paths can lead to container setup timeouts, again presenting as CLF until transient conditions subside.

Quick things to try in Community Edition

Because CE is locked down, the most reliable mitigations are operational:

Terminate the failed compute, create a brand-new compute, and start it again. If it fails, wait 20–30 minutes and retry — these incidents are often transient and clear with time.
If the CE UI exposes a different Databricks Runtime option, try starting with a different runtime version once to rule out a runtime-specific transient.
Avoid rapid stop/start cycles on the same compute instance. Give it ~10 minutes between attempts to reduce chances of instance/container reuse conflicts.
If you can open the Event Log for the compute, capture the cluster ID and the UTC timestamp of the failure. Those two details make it easier to correlate against known transient patterns and provider incidents.

Why this isn’t your configuration

You’re right that CE locks down most cluster settings, so user error is unlikely here. The patterns above are internal, provider, or transient pipeline issues that present as CLF; they’re frequently resolved by retrying or avoiding instance reuse.

If it keeps failing

If you’ve tried the steps above multiple times across different days and still can’t get a compute to launch, please share: The CE workspace URL, the cluster ID, and the most recent failure time (UTC). A screenshot or copy of the compute’s Event Log around the failure.

With those, we can reason further about whether you’re hitting an ongoing provider-side condition (e.g., capacity or bootstrap timing) versus an intermittent image download path, and advise the next best step.