Runtime changelog, 21 October 2026
What shipped in Runtime Cloud on 21 October 2026: a slow upload is told as slow, not as our timeout; 30 days to top up; many copies of a large snapshot at once can be asked to retry; a scheduled job keeps data between runs on a volume; a full region answers 503, and an account at its limit 429; every error says whether to retry it, and its status means what HTTP says; the SDKs read retryable; a pause succeeds when its server's snapshot space is full; and accounts without credit hold up to 10 API keys.
A slow upload is told as slow, not as our timeout
A request whose body is still arriving when the API's 110-second answer deadline passes, such as a chunk of a large upload over a busy link, is now answered 408 request_timeout with the bytes received so far, where before it was answered 503 api_unavailable, as if the API were at fault. The SDKs and the CLI get 503 body_stalled and send it again by themselves, as they did before. Many uploads at once over one slow link share it: send fewer at once, or send again with the same Idempotency-Key (a chunk at its same offset). See errors.
30 days to top up
When credit runs out in an account that has bought credit or saved a card, its stopped and paused sandboxes' disks are kept 30 days, not seven, with a notice first and a warning the day before, and adding credit in that time keeps them. Other stored items, and every item in an account that has done neither, keep their seven days. See when your balance runs out.
Many copies of a large snapshot at once can be asked to retry
A copy of a snapshot that saved memory, and a wake, load all of that memory within seconds, and a server now counts each one at all of it from its start, not a quarter. A burst of copies or wakes bigger than one server's memory no longer overfills it: the ones past its room wait while it makes room, and if none comes in time answer 503 host_memory_pressure with Retry-After. Send them again after it, with the same Idempotency-Key, as the SDKs do. See errors.
A scheduled job keeps data between runs on a volume
A job's compute.volumes attaches up to four of your volumes to every run, each at a path, as a sandbox create does: read-write, one run at a time, so each run reads what the last one wrote, or a read-only snapshot copy. In the CLI, runtime jobs create ... --volume <id>:/data, and for a job you already have, runtime jobs update <job> --volume <id>:/data or --no-volumes; in the SDKs' next release. A run that waits for its volume says so with blockedReason volume. See Keep data between runs.
A full region answers 503, and an account at its limit 429
No room for a sandbox, a fork, a restart, a wake, a build or a volume, no_capacity, is now 503 Service Unavailable with Retry-After: 1. The account at a limit on what runs at once, quota_exceeded or no_credit_running_limit, is now 429 Too Many Requests with Retry-After: 5. All three were 409 Conflict, which a client that retries only 5xx and 429 gave up on. Such a client now retries them with no change. The body is the same, so code that reads error.code keeps working. In the SDKs' next release the error's class follows the status: no_capacity is a ServiceUnavailableError, and the two limits are a RateLimitError, not a ConflictError. The SDKs still wait them out on create, wake and restart, and return them at once elsewhere, as before. See errors.
Every error says whether to retry it, and its status means what HTTP says
Each error now has retryable, true or false; a retryable one always carries a Retry-After header, and no other does. Each code has one status, listed with every code in Responses and errors and in the OpenAPI document's x-error-codes. Codes are unchanged, so code that reads code keeps working; a check on the status may need a look: - 409 is now only a state you change first, or one that clears by itself (snapshot_not_ready, image_not_ready, volume_releasing, ... are retryable). - Your own limits that clear by themselves are 429, always with Retry-After: quota_exceeded on what runs at once (details.limit such as sandbox.count or sandbox.memory_mib), the no_credit_* limits on what runs, process_limit, transfer_limit, guest_busy, build_in_progress and the daily caps. - A count that falls only when you delete something is 409, with retryable: false and no Retry-After, so no retry library retries it: no_credit_kept_limit, limit_reached (keys, invitations, compartments) and quota_exceeded on what is kept (volumes, snapshots, images, secrets, sandbox.kept). Delete one, or raise the limit. - A full region or host is 503 with Retry-After: no_capacity, host_capacity, own_share_full. - A product switched off on a deployment is 501, not 503, so no client retries it. - A fault of ours that a retry does not fix is 500 (operation_failed, price_unavailable, and watch_failed: Runtime's own file watcher in a sandbox); a service behind the API is 502 or 504. - A request that cannot be done as asked is 422: disk_too_small, idempotency_conflict, no_credit_size_limit, a program in your sandbox that failed (interpreter_failed, tunnel_unavailable).
The SDKs read retryable
The SDKs read retryable (in the same versions). They retry an answer that says retryable: true after its Retry-After, and never one that says false. A create, wake or restart waits out room and the account's limits for its own wait for room (two minutes by default; 0 returns at once), and a fork returns them at once. An answer whose wait is over a minute (a daily cap) is returned at once, with retryAfterMs. The Go, Ruby and Java SDKs now also resend a call refused guest_busy, busy or rate_limited until its deadline, as JavaScript and Python do. The CLI's --json errors carry retryable and retryAfterMs.
A pause succeeds when its server's snapshot space is full
Saving a snapshot now leaves the room each server keeps for pausing the sandboxes it runs. When that room is short, the server makes room while the pause waits, up to about a minute: it compresses saved memory images, moves kept snapshots to other servers, and copies paused sandboxes to storage and shrinks them. If there is still no room, the sandbox is paused all the same: the server holds its memory and saves it once there is room, and a wake meanwhile resumes it at once. Such a pause used to fail. Only a sandbox too near the end of its time to save its memory later is not paused: the pause fails with no_capacity (503, retryable) and the sandbox keeps running, its memory intact. A snapshot the server has no room for is refused with host_capacity (503); retry it later. See pause, wake, extend.
Accounts without credit hold up to 10 API keys
A new key past ten is refused with no_credit_key_limit (409) and says how to make room: revoke a key you no longer use, or add credit, after which there is no limit. Every key an account already holds keeps working, and keys Runtime makes for the console, its terminals and image builds are not counted. See free usage.