When Your Cloud Workspace Won't Start

You ask for a cloud workspace, wait, and get an error that explains nothing. You did not change anything. Your teammate spun one up an hour ago. The repository is fine.

This is one of the more frustrating failures in modern development, because the thing that broke is usually not in your code, not in your configuration, and not visible from where you are standing. Here is how to tell the causes apart quickly, and what to do about each.

Most of the time it is account state, not your setup

When a cloud workspace fails to create within a few seconds of asking, the provider rejected the request before any environment was built. Almost always, the reason is a state on your account rather than anything about the project.

Included usage is exhausted. Most cloud development platforms include a monthly allowance of compute hours. When it runs out, creation fails. This one is confusing because it is not a hard failure — it is a quota failure, and quotas reset. A workspace that failed on the 28th may create perfectly on the 1st.

A spending limit is capping paid overage. This is a separate control from the allowance, which is why raising one does not always help. A limit of zero blocks paid usage entirely; if you still have free hours, you will not notice, and the moment those run out, creation stops with no obvious connection to the setting you configured months ago.

A payment method has lapsed. An expired card produces the same class of rejection as an exhausted allowance.

A concurrency limit is reached. Some plans cap how many workspaces can exist or run at once. Old workspaces you forgot about count. This one is genuinely easy to fix and easy to miss.

The tell for all four is timing. If the failure arrives within a few seconds, nothing was ever provisioned — the request was rejected up front. If it arrives after a minute or more, the environment started building and something inside it failed, which is a different investigation entirely.

The error message will probably not tell you which

This is the part worth internalising: providers are inconsistent about how they report billing-class rejections. The same underlying condition can surface as a 402, a 403, or — commonly — a plain 400 with a generic message.

We have watched a single account hit all three across a few days with no change on our side or theirs. The same repository that created a workspace on Monday returned a bare 400 on Wednesday and a clean, explicit 402 the following week. The underlying condition never changed; only the reporting did.

So do not take the HTTP status at face value, and do not assume a 400 means you sent something malformed. When the failure is instant, check account state first regardless of what the code says.

The five-minute triage

Check the timing. Instant rejection means account or quota. Slow failure means the environment was building — look at your dev container configuration, base image, and setup scripts instead.

Open your provider's billing page directly. Not the settings page for the project — the billing page for the account that owns the workspace. Look at three separate things: remaining included hours, the spending limit, and the payment method. They are independent, and any one of them stops creation.

Count your existing workspaces. Include stopped ones. Concurrency and total limits usually count both. Deleting a workspace you finished with three weeks ago solves this instantly.

Confirm who is being billed. If the repository belongs to an organisation, the workspace may bill the organisation rather than you — or the reverse. Failures often appear right after a repository moves between accounts, because the billing relationship changed while nothing about the code did.

Try a different repository. If a small public repository creates a workspace successfully, the problem is scoped to the original repository or its owner, not your account.

The retry trap

The natural response to an unexplained failure is to try again. With account-state failures, retrying cannot work — the condition is unchanged — and it has a real cost: some platforms count repeated failed attempts against rate limits, and you can end up unable to create a workspace for reasons unrelated to the original problem.

If the first two attempts fail identically and instantly, stop. Go and read the billing page. The third attempt will fail the same way.

Have a fallback that does not depend on that provider

The strategic point is that this class of failure is entirely outside your control and, at the worst possible moment, terminal. You wanted to start work. Now you are in a billing console.

Every serious workflow should have somewhere else to run:

Your own machine, with the agent or tooling running locally. Slower to set up the first time, immune to somebody else's quota.

Your own server. A small VPS you control removes the entire category of problem for long-running or overnight work.

A different cloud provider. Keeping a dev container definition that works on more than one platform costs little and means a quota wall is an inconvenience rather than a stop.

What matters is that the fallback exists before you need it. The failure always arrives when you have thirty minutes and something to finish — which is exactly when nobody wants to configure a new environment from scratch.

This is why we treat a blocked workspace as a first-class product state rather than an error to display. When the cloud rejects you for reasons that have nothing to do with your work, the useful response is not a better error message. It is somewhere else to run, ready to go, with the same repository and the same agent, so the interruption costs you a minute instead of an afternoon.