# Runtime errors

> What the error pages on a prototype preview mean and how to fix each one.
> URL: https://artor.app/docs/runtime-errors

If a prototype won't open, use the message on its error page to choose a fix below.
For a startup crash, open **Details → Logs** and give the error to your coding agent.

Static pages do not need to start an app, so these startup errors do not apply to them.

## What you'll see

While a prototype starts after being idle, everyone sees a brief auto-refreshing loading page -
that's normal and resolves within seconds. The error pages below appear only when the
start actually failed.

| Page | Meaning |
| --- | --- |
| **This version needs more memory** | The prototype needs more memory than your plan allows. |
| **This version crashed while starting** | The prototype exited or never became healthy, for a reason other than memory. |
| **The organization is at its running-prototype limit** | The plan's concurrency cap is in use; nothing is wrong with this version. |
| **This prototype is temporarily unavailable** | What visitors on a public share link see for any of the above. |

**Note:** 
  Organization members see the real cause and the fix. Visitors holding a public share link
  always get the generic "temporarily unavailable" page - a public link never reveals the
  organization's plan, memory limits, or crash details.

## Needs more memory

The prototype needs more memory to start than your plan provides.
Two ways to resolve it:

1. **Upgrade the plan.** An organization admin can review and change the plan under
   **Settings → Billing**. A higher tier raises the memory available to each prototype; the next
   time the prototype wakes, it starts with the new cap.
2. **Reduce the prototype's startup memory.** If the plan is already right, the prototype
   itself is using too much memory before it serves its first request. Paste this into
   your AI coding assistant, substituting the limit shown on the error page for N:

   > My prototype cannot start on Artor because it needs more than N MB of memory.
   > Find what is using the memory, reduce it, and help me publish a working version.

After either fix, use **Try again** on the error page (memory errors pause retries for
about a minute, so a fixed plan takes effect on the next attempt), or simply publish
again - a fresh publish always starts clean, with no wait.

## Crashed while starting

The prototype could not finish starting. Its Logs can help your coding agent find the cause.

1. **Read the crash log.** Artor saves the startup error. Run
   [`artor logs`](https://artor.app/docs/cli#reading-a-crashed-versions-logs) in the linked folder (add
   `--json` for output an agent can read), or open the version's **Details** sheet in the
   dashboard and switch to the **Logs** tab.
2. **Ask your coding agent to investigate.** Give it the error and ask it to reproduce the
   problem locally. It can check for a missing dependency or [configuration](https://artor.app/docs/env).
3. **Fix and publish again.** A new publish is a new version and starts immediately -
   it is never held back by the previous version's failed attempts.

The version's row on the prototype page also shows a **Failed to start** badge, so you
can spot a broken version from the dashboard without opening the preview.

If you haven't set up terminal commands, see [Installing the CLI](https://artor.app/docs/install-cli).

## Crash logs

When a prototype fails to start, its Logs show the error details:

- **Bounded.** Capture is capped at 512 KB per version - enough for a stack trace and its
  lead-up, never a runaway log.
- **Latest failure wins.** One log is kept per version; a repeated failure on the same
  version overwrites it, and a version that later starts successfully clears it.
- **Secrets are scrubbed.** Your organization's [environment variable](https://artor.app/docs/env) values
  are hidden when they appear exactly as saved. Values changed by your prototype may not be
  recognized, so check logs before sharing them.
- **Where to read them.** [`artor logs`](https://artor.app/docs/cli#reading-a-crashed-versions-logs) from
  the linked folder, or the **Logs** tab on the version's Details sheet in the dashboard.
  Members with access to the prototype can read them; public visitors can't.

A version that never crashed still shows its **live** log tail in the same places while it
is running.

## At the running-prototype limit

The organization is already running as many live-app prototypes as its plan allows. Nothing
is wrong with this version:

- **Wait a few minutes.** Idle prototypes stop automatically, freeing a slot, and the
  page's Try again link picks it up.
- **Upgrade the plan** (Settings → Billing) to run more prototypes at once if the team hits
  this often.

## Public share links

A visitor on a [public share link](https://artor.app/docs/sharing) sees one generic page - "This prototype
is temporarily unavailable" - for every cause above. If someone reports it, an organization
member can open the same version while signed in to see the real cause and the fix.

## Limits

- These pages cover **start-time** failures. A prototype that starts fine and crashes
  later restarts on the next visit. Artor does not capture a startup log for that later crash.
- A memory problem can sometimes appear as a startup crash. Your coding agent can help
  check the logs and determine which fix is needed.