Errors

הדף הזה עדיין לא תורגם לעברית: הנה הוא באנגלית.

Every error has one shape:

{"error": {"type": "forbidden", "code": "plan_cap_reached", "message": "…", "param": "vcpus",
           "retryable": false, "request_id": "req-…", "docs_url": "https://glac.ai/docs/errors/#plan_cap_reached"}}

code says which failure it is, for programs; message says it for people, with what the limit is and what lifts it; param names the field or the limit at fault; retryable: true means the same call may succeed later, with Retry-After where that is known; request_id is the call’s, in its X-Request-Id too.

docs_url, where an error has one, leads here, to its code. The codes below have a section of their own: the refusals whose message sends you to this page, every refusal of a limit (of a plan, of a project, or of the platform’s), those that come of the platform’s machines (full, away, changing hands, or unable to do what was asked), one a visitor to a sandbox’s or an app’s address may get, and a few more about money. Every other code is described under each call that answers it, in the API reference. The numbers of each limit are on the limits page, and the limits we raise for one account on request on raising a limit.

plan_cap_reached

403: the call would take the account past what its plan lets it have at once, or make things faster than it lets it. param names the limit: instances, vcpus or memory_bytes (awake, in all the account’s projects), sleeping (sandboxes kept asleep), app_instances (an app’s instances in a region), creates_per_minute, creates_per_hour_per_project or app_creates_per_hour. The message says the limit, whether it is the plan’s or one set for the account, what is used, and what the call would add.

• What it refuses: making sandboxes, one-shot runs, forks and keyed instances; a call that wakes a sleeping sandbox (a command, its files, a restart, a snapshot, a restore); an app whose scale asks for more instances than the plan lets it have; Cubes and versions past those of the hour. A request at a sandbox’s link or a keyed instance’s address that would wake one is refused the same way by its machine, and nothing wakes (each machine wakes within its part of the account’s room: one may refuse for a few seconds while the account has room left on another, which the message says); so is a request to an app that would wake or make an instance the account has no room for, at once, with the same param and words. Putting to sleep and deleting are never refused.
• What to do: put something to sleep or delete it; for the three rates, wait (they are retryable, with Retry-After). On Free, move to Paid, whose limits are larger (glac billing plan paid). Or ask us to raise the limit for the account: see raising a limit. GET /v1/account (caps) shows each limit with what is used now.

The numbers of each plan are on the limits page.

volume_limit_reached

403: a volume more than the plan of the project’s account lets a project keep, one larger than one may be, or more than they may hold together (param size_bytes of the last two). The message says the plan’s numbers, what the project has, and the ways out: delete a volume, ask for a smaller one, or move to Paid, which keeps more. On Paid the number of volumes is a soft limit, which we raise on request; an enterprise account may also have volumes larger than any plan’s, up to 16 TiB. See raising a limit.

drive_limit_reached

403: the same of Drives: a new Drive, a fork of one, or the Drives a sandbox gets when it is made from a snapshot that carries them, would take the project past the Drives its plan lets it keep (how many, how large each, how large together). The message says the plan’s numbers, what the project has, what the call would make, and the ways out, as for volumes: on Paid the number of Drives is raised on request, and an enterprise account may have Drives of up to 16 TiB. A Drive’s snapshots are not counted. See the plans’ numbers and raising a limit.

spend_limit_reached

403: a spend limit is reached, the project’s or a sandbox’s own (PATCH /v1/limits, PATCH /v1/sandboxes/{id}/limits); the message says which, and what lets it go. Nothing new is made in a project at its limit (no sandbox, volume, Drive or snapshot, no version of an app), and a sandbox the limit froze is not woken. A request through a sandbox’s link or an app’s address, for a sandbox or an app that is frozen or stopped, is answered with this code too, whatever stopped it.

• What to do: raise the limit, or take it away (null), and what it froze can be woken by the next call that needs it. The month’s spending starts again at the next month. See spend limits.

quota_used_up

429, on Free: the account has used up today’s quota (UTC) of what the call would use. Which meter it was decides what stops, whatever the account holds:

• CPU time or memory: its sandboxes sleep, with their data, nothing new is made in its projects, and a call that would wake one is refused;
• requests: the edges answer its sandboxes’ and apps’ requests with this code;
• traffic to the internet: what its sandboxes send to the internet stops;
• logs: what its apps print is no longer kept.

retryable, with Retry-After the seconds until 00:00 UTC, when the quotas come back whole and what stopped goes on by itself. Free is never charged: Credits the account holds pay for nothing on it. GET /v1/billing says what is used of each quota today (meters) and which meters are stopped (meters.*.stopped).

• What to do: wait for 00:00 UTC, or move to Paid (glac billing plan paid, or PATCH /v1/billing with plan paid), which has no daily quota: each month it includes a quantity of each meter, and past it usage is paid from the balance. See when a meter runs out.

storage_quota_reached

403, param storage, on Free: the account keeps as much as Free lets it keep at once, 15 GB of volume data (what its volumes hold, and what its snapshots and sleeping sandboxes keep) or 15 GB of NVMe cache. That is a level, not a quota of a day. A new volume or snapshot is refused; nothing that is kept stops or is deleted. The level is read from the last whole hour’s books.

• What to do: delete what is not needed, and once the account keeps less a new one is made again; or move to Paid, which includes a quantity of data each month and prices what is kept past it. GET /v1/billing shows what is kept (meters.volume_data, meters.volume_cache).

balance_used_up

403, on Paid: what the account’s period includes of CPU time or memory is used up, and the account holds no balance to pay for more. Its sandboxes are frozen, nothing new is made in its projects (no version of an app either), and a call that would wake a frozen sandbox is refused.

• What to do: top up the balance (POST /v1/billing/topups, or the console’s billing page), or turn on auto reload. Otherwise it lasts until the next period begins. GET /v1/billing says which meter is stopped (meters.*.stopped) and when the next period begins. On Free, a quota of the day used up is 429 quota_used_up instead. See when a meter runs out.

needs_balance

403, param egress_overage, of PATCH /v1/account with egress_overage: pay, by an account on Free or one whose balance holds nothing: traffic to the internet past what Paid includes is paid from the balance of an account on Paid. Nothing is changed: past what the plan includes, the traffic stops. GET /v1/billing shows the plan, the balance and what is used of each meter.

• What to do: be on Paid (PATCH /v1/billing with plan paid) and top up the balance (POST /v1/billing/topups, or the console’s billing page). An account on Paid that holds a balance pays for the traffic past what Paid includes by itself, and its egress_overage reads pay; egress_overage_cap_bytes caps it. See the balance.

plan_limit_reached

403, to a request through a sandbox’s link, an app’s address or a domain: the account’s traffic to the internet is stopped (on Paid, it has sent what its period includes and holds nothing to pay for more; or it reached its own monthly cap), or, from an edge only, it has used up the requests its period includes and holds nothing. Answered by the edge, or by the machine, before anything of the owner’s runs. What a quota of Free’s day stops is 429 quota_used_up instead.

• What to do: as for balance_used_up: top up, or wait for the next period; a cap of the account’s own is raised with PATCH /v1/account (egress_overage_cap_bytes), and lasts until the next calendar month otherwise. See when a meter runs out.

plan_size_exceeded

403: the sandbox would be larger than the account’s plan lets one be: the limits asked for (param limits.vcpus, limits.memory_bytes, or limits for both), or the shape of the snapshot, template or sandbox it is made from, forked from or taken back to. A sandbox that names no size is never refused for this: it is made as large as the plan allows at most. A sandbox larger than Free allows, of an account back on Free (its subscription ended), sleeps with its data and is not woken until the account is on Paid; nothing of it is deleted or made smaller.

• What to do: ask for a smaller size, or move to Paid, whose largest sandbox is larger (PATCH /v1/billing with plan paid). The largest of each plan is on the limits page.

paid_plan_required

403, param the field: what the call asks for is had on Paid alone, and the account is on Free: a database’s tiered storage (tiering.enabled). Nothing is changed. GET /v1/billing shows the plan the account is on.

• What to do: move to Paid (PATCH /v1/billing with plan paid, or the console’s Billing page), then make the call again.

proxy_not_on_plan

403, param proxy: a Browser session is given a proxy of its own on Free, which has none. Nothing is made or changed.

• What to do: make the session without proxy, or move to Paid (PATCH /v1/billing with plan paid). GET /v1/billing shows the plan the account is on.

secret_limit_reached

403: a secret more than the plan of the project’s account lets a project keep (a secret the project has is changed whatever the number), a value larger than one secret may be (param value), or one that would give an app’s instances more of the project’s secrets than one sandbox may be given (the message names the app). The message says the plan’s number.

• What to do: delete a secret the project no longer needs (DELETE /v1/secrets/{name}), keep a smaller value, or move to a plan that keeps more. See the plans’ numbers.

app_limit_reached

403: the account has as many apps, in all its projects, as its plan lets it have. Waiting changes nothing.

• What to do: delete an app it no longer needs (DELETE /v1/apps/{app}), or move to Paid, which has more. See the plans’ numbers.

env_limit_reached

403: the app would have more environment variables and secrets together than the account’s plan lets one app have.

• What to do: give the app fewer of them (a shared variable, /v1/variables, can hold what several apps read), or move to a plan that lets an app have more. See the plans’ numbers.

key_secret_limit_reached

403, of POST /v1/apps/{app}/key-secrets: the app has two secrets its keys are signed with, the most it has.

• What to do: delete the one its keys are no longer signed with first (DELETE /v1/apps/{app}/key-secrets/{secret}). See keyed instances.

domain_limit_reached

403: the project has as many of its own domains as a project may have (100).

• What to do: delete a domain it no longer serves. See the limits of the API.

variable_limit_reached

403: the project has as many shared variables as a project may have (1,000).

• What to do: delete a variable it no longer uses. See the limits of the API.

destination_limit_reached

403: the account has as many destinations of its apps’ logs, in all its projects, as its plan lets it have.

• What to do: delete a destination it no longer exports to, or move to a plan that has more. See the plans’ numbers.

account_share_reached

403: something new of the account (a sandbox, a one-shot run, a fork’s copies, a snapshot, a volume or a Drive) would take it past its share of the data drive of the machine it would be on: one account holds at most a share of a machine’s drive, a quarter unless the machine is set otherwise, everything of its own there counting. The platform puts what is new on a machine where the account has the room, and passes this on when none has. The message says what the account holds there, what it may, and what this would need.

• What to do: delete what the account no longer needs (sleeping sandboxes, snapshots, Drives), or make the new thing again in a moment, which may find a machine with room. A machine’s share is not raised for one account.

app_rate_limited

429, with Retry-After: 1: the app had as many requests a second at this edge as its account’s plan gives an app there (Free’s number; Paid has none). The request reached no machine, woke and made nothing, and is not counted or billed.

• What to do: send it again after a second, or move to Paid. See the plans’ numbers.

too_many_followers

429, retryable: as many readers follow the logs of the account’s apps at once as its plan lets follow (logs.followers of GET /v1/account).

• What to do: end a reader that follows (a glac cube logs -f left open, a page’s stream), or try again in a moment. See the plans’ numbers.

egress_connections_full

503, retryable, to a sandbox’s own connection out: the account’s sandboxes on this machine have as many connections through its egress proxy at once as the account’s share lets them have together. A plain HTTP connection is answered so; a TLS one ends with an alert, any other is reset. Every other account’s connections go on.

• What to do: close connections that are not used, or keep fewer open at once; try again in a moment. See connections out.

too_many_drives

409: a sandbox would have more than 8 Drives and volumes of its own, the most one has.

• What to do: give the sandbox fewer, or keep the data of several in one Drive. See Drives’ limits.

too_many_volumes

409, param volumes: a sandbox would have more volumes of its own (not shared) than its machine has spare drives for: 8, the most a sandbox has, or 2 for a sandbox made from a template or a snapshot of before there were 8, until it next starts from its disk. Shared volumes are not counted. GET /v1/sandboxes/{id} lists the volumes a sandbox has.

• What to do: give the sandbox fewer, keep the data of several in one, or share one (a shared volume is not counted). This is the platform’s limit, the same on every plan.

too_many_projects

409, of POST /v1/accounts/{id}/projects: the account has 100 projects, the most an account has.

• What to do: delete a project it no longer uses.

too_many_free_accounts

409, of POST /v1/me/accounts: the user owns as many accounts on Free as one user may.

• What to do: make the new account’s projects in an account the user has, or move one of its accounts on Free to Paid.

too_many_revoked_tokens

409: a token of a sandbox is to be revoked by itself, and the sandbox keeps as many tokens revoked one by one, that have not run out, as it may (1,000; param token).

• What to do: revoke every token of the sandbox at once (POST /v1/sandboxes/{id}/tokens/revoke with no body), and sign new ones after it. See one token alone.

too_many_ssh_keys

409, of POST /v1/ssh-keys: the project has 1,000 SSH keys registered, the most a project has. GET /v1/ssh-keys lists them.

• What to do: delete keys that are no longer used (DELETE /v1/ssh-keys/{id}, glac sandboxes ssh-keys rm). See SSH.

too_many_forwards

503, retryable: the sandbox has as many connections open from the SSH gateway at once as one sandbox may (SSH sessions’ port forwards and agents together: 64, unless its machine is set otherwise), and a new one is refused. Those open go on.

• What to do: close forwards that are not used, or try again when one of them has ended. See SSH.

rate_limited

429, retryable, with Retry-After: too many tries for now, of a sign-in, a sign-up, a new password by mail, a mail that verifies an address, or an invitation: of one address, from one source, of one user or of one account. The try counts for nothing, and the refusal says nothing of whether the address has a user.

• What to do: try again after Retry-After.

report_in_progress

429, retryable, of GET /v1/usage: another report of the same project’s usage was still being made after 2 seconds. A project’s reports are made one at a time.

• What to do: ask again when the other has been answered.

too_many_connections

429, with Retry-After: 1, from an edge: it carries as many requests from the client’s address at once as it carries from one address. Nothing of the owner’s ran.

• What to do: send it again after a second, or open fewer connections at once from one address.

body_too_large

413: the request’s body is larger than its call takes; the message says the limit. The connection is closed. A file’s content is not held to it: see the limits of the API.

• What to do: send less in one call: a command’s input in parts (…/exec/{exec_id}/stdin), a file through the files’ calls.

no_capacity

503, retryable: no machine can take what the call would make right now, and nothing was made. The message says why: no machine has room for it (those there are full, or are given nothing new for now); none has room on its disk to build the image; none of those asked can fetch the image (param image); none that has what it is made from, or can have it from its object store, is there; or, of a volume made from a backup, no machine of the backup’s region that copies to the object store is there. It is a refusal of the moment, not of your plan: the plan’s limits are quotas, not reservations (limits).

• What answers it: chiefly the calls that make something: a sandbox, a one-shot run, a fork, a keyed instance, a volume or a Drive.
• What to do: make the call again a little later. The SDKs make it again a few times by themselves, as their retries say, before they raise it.

strict_unsupported

409: a strict Drive where it cannot be kept strict: on a machine that copies nothing to an object store, or mounted in a sandbox made from a template built before strict Drives, whose machine cannot pass its guest’s flushes on. Nothing was made or mounted. Mount it in a sandbox made from a newer template (one made now), or make the Drive standard.

standby

503, retryable, with Retry-After: the call reached a copy of the control plane that is not the one serving. The control plane runs in two copies, in two sites; while one takes over from the other (its site lost, an upgrade), calls are answered so, and active names the copy that serves where this one knows it. Nothing was done. Make the call again after Retry-After: the SDKs do so by themselves, as many times as their retries say. See when a machine is lost.

fenced

503, retryable: the machine that has the sandbox has not heard from the control plane for longer than its lease, and cannot tell whether the sandbox is still its own: it may have been taken over on another machine meanwhile. It starts nothing for the sandbox and answers nothing of it until the control plane says; the call waited three seconds for that first. Make the call again: once the control plane has answered, it goes to wherever the sandbox is. See when a machine is lost.

checkpoints_unavailable

409, param checkpoint: checkpoints asked for where no machine can take them: no machine of the platform copies its disks to an object store and keeps memory in layers, or what the sandbox is made from is on a machine that does not, or a PATCH turns them on for a sandbox on such a machine. Nothing was made or changed. Make the sandbox without checkpoint, or from something a machine that takes checkpoints can have. While every such machine is away or full, the same call answers 503 no_capacity instead.

malformed_answer

502, not retryable: a visitor to a sandbox’s link or an app’s address is answered so by the machine in front of it, in two cases. The first: what the service in the sandbox answered contradicts itself on its length (Transfer-Encoding and Content-Length both, or a Content-Length that is no number or has two values), and nothing of that answer is passed on. The second: the service took the request and closed the connection without answering at all, for example because the sandbox’s kernel ended the process when its memory ran out. The platform does not send the request again, since the service may already have acted on it.

• What to do: in the first case, fix the service’s answer: one of the two length headers, never both. In the second, look at why the process stopped: the output of the command that runs the service (glac sandboxes logs), and the sandbox’s memory and its settings (glac sandboxes get). Send the request again only where doing it twice is harmless.

account_held

403: the account is on hold for its payments, until support has looked at it. Meanwhile:

• every call of its projects’ keys and of its sandboxes’ tokens is refused, but GET /v1/account, whose payment_hold says since when;
• its sandboxes sleep, with their data, and requests for its apps and sandboxes are refused; a deploy under way fails, and the traffic stays on the versions it had;
• nothing is charged to it, and nothing of it is deleted.

The account is mailed once when it is put on hold (the notice account_held). Neither the API nor the mail says why: write to support@glac.ai with the account’s id to have it looked at.

account_in_debt

402: the account owes. What it keeps past the storage its plan includes (sleeping sandboxes, snapshots, volumes and Drives) is paid from its balance, and with nothing to pay it the balance went below zero, by $0.50 or more. Until it has paid:

• every call of its projects’ keys and of its sandboxes’ tokens is refused so, but those that read what it owes (GET /v1/account, GET /v1/usage, GET /v1/events, the reads under /v1/billing), those that pay it, and deleting what it stores;
• its sandboxes sleep, with their data, and requests for its apps and sandboxes are refused.

It is mailed when the debt begins and reminded after; thirty days after the first mail, what it stores is deleted and the debt written off.

• What to do: pay what it owes: a top-up (POST /v1/billing/topups, or the console’s Billing page) that brings the balance to zero or above ends it at once. GET /v1/billing shows the balance. See an account that owes.

user_locked

403: the user is locked. Signing in to the console, with a password, GitHub or Google, and the link that chooses a new password are refused (a sign-in is told so only with the right password). Write to support@glac.ai from the user’s address.

billing_address_required

409, param billing_address: a charge to the card that nobody is there to make (a top-up through the API, Paid’s fee, turning auto reload on) needs to know where the account is, for its tax, and the account has no billing address and its card does not say its country. Nothing is charged. Set the billing address (glac account billing-address --country DE, or PATCH /v1/account with billing_address), or pay on the payment page (POST /v1/billing/checkout), which asks for it. The console’s Billing page asks for the address before it changes the card.

trust_limit_exceeded

403: a top-up, an auto reload or a spend limit past what the account’s trust level lets it be charged this month. The message says the level, what is used this month and when the level rises by itself. Support raises a level on request: see trust levels and raising a limit.