# When something fails (https://lazyfrog.dev/docs/guide/when-something-fails)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

- Errors have a `code` (for example `validation_failed`, `not_found`, `confirm_required`,
  `workspace_busy`, `plan_limit`, `node_unreachable`) and a message that says what to do.
- Read `logs_tail` and `service_status` before retrying. Repeating a failing call unchanged will
  not help.
- After fixing something that failed, request it once more before calling it fixed (a commit or a
  ticked plan item reminds you of one you haven't). If it fails again the same way, stop and tell
  the user what you tried, what it says and what you think is needed; don't keep changing things.
- `http_get`'s and `http_request`'s `service_restarting` means the app's service is starting again: retry in a few
  seconds. `service_crashed` means it stays down: fix the cause from `logs_tail`, then `service`
  `restart`; retrying the request won't help.
- `workspace_out_of_memory` means the call failed because the workspace is out of memory. It names
  what holds the memory now (the biggest services and the database), the workspace's memory on
  its plan (on Free and Hobby a command already had 512 MB more for its run), and the options:
  restart, stop or remove the service holding it (`service`), run the heavy work differently (a
  smaller batch, a stream, fewer workers, a `LIMIT`; a production build through `deploy
  preflight` on a paid plan, or with the dev server stopped on Free), free memory (cancel jobs you
  no longer need), or the owner upgrades for more (the `upgrade_url`). The same call again won't
  help: within a few minutes, with nothing changed in the workspace, it is answered at once
  without running (`ran: false`), and after a few repeats it says to stop. Change something
  first, or tell the user and ask how to go on. With `node_busy: true` the command had no extra
  room because the node was busy: try it once more in a few minutes before changing course; it
  isn't a reason to upgrade.
- If the platform is at fault and the user wants help from a person, say so and, only when they ask
  you to contact Support, open a `support request` with the `correlation_id` from the error (after
  they have seen the text; `user_asked: true`, `confirm: true`).
- When the platform got in your way (a tool couldn't do what the user needed, this guide or an
  error misled you, something was missing for their stack), tell LazyFrog with `feedback`: what
  you were trying to do and what happened, in a sentence each. It's how the platform improves;
  it never reaches the user, so tell them yourself, and carry on with a workaround if there is
  one. Never put secrets or the user's personal data in it. When only a checking tool fails
  (`preview_try`, `preview_screenshot`, `design_check`) and the site answers right another way
  (`http_get`), the fault is the tool's: report it and say how you checked instead, but don't
  change the site to suit the tool.
- `waitlisted` means LazyFrog is at capacity for new free accounts: this account is in line to
  start building. Tell the user their place in line and that they get an email when their spot is
  ready; a paid plan starts at once. Don't retry until then.