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.

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:

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.
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.

Read the crash log. Artor saves the startup error. Run artor 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.
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.
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.

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 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 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.

A visitor on a public share link 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.