Previews are never indexed
Every answer on a preview address, private or public, carries X-Robots-Tag: noindex, nofollow, and each preview address serves Runtime's own robots.txt, so no preview shows up in search. A custom domain serves your site's own headers and robots.txt; use one for a site that should be found. See search engines.
First in line by plan when room is short
When a region is short of room, the room that frees goes first to the highest lane waiting for it: Enterprise, then Scale, Pro Max, Pro and Free, from the account's plan, and Runtime's own work after every customer's. Until an account chooses a plan, paying accounts go before trials. A create or wake refused no_capacity keeps its place while it is sent again with the same Idempotency-Key, as the SDKs do, and the refusal says its place, how many wait ahead and its lane, also in details.line. Nothing already running is stopped for a higher lane. See waiting in line for room.
A slow upload is given the time to arrive
A request's 110 seconds to answer now start once its body has arrived, so a chunk of a large upload over a slow or busy link is no longer cut while its bytes are still coming in, and answered 503 api_unavailable as if the API were at fault. A body may take up to about 280 seconds to arrive. One still arriving after that is answered 408 request_timeout with the bytes received so far; the SDKs and the CLI get 503 body_stalled and send it again by themselves. Many uploads at once over one slow link share it: send fewer at once. See files.
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.
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.
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.