When something fails

What your AI does when a build, a command or a publish fails on LazyFrog: read the error, find the cause, and fix it at the source.

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.