Publish Errors Now Say What Happened, in Plain Words
When a Mythex publish fails, you now get one plain sentence about what went wrong, plus Fix with AI and Try again — instead of raw hosting output.
Mythex Team · · 4 min read
When a publish fails on Mythex, the dialog now tells you in one plain sentence what happened — the build failed, your app stopped after it started, your app never started, a file is too big, or something went wrong on our side — and offers Fix with AI and Try again. The raw output from the build and your app still reaches the agent, so Fix with AI can read it and fix the project, but you no longer have to read it yourself.
What changed
One sentence you can act on
Every failed publish now has a type, decided at the moment it fails from facts we have there — which step failed, whether the app's machine reported crashes, whether it ever started accepting connections — rather than by reading the error text afterwards. Each type has its own message:
| What you see | What it means |
|---|---|
| "The build failed." | Your project's build command or Dockerfile didn't build. |
| "Your app stopped right after it started." | It published, then exited or kept restarting. |
| "Your app didn't start after publishing." | It was published but never began accepting connections. |
| "This file is too big" / too many files | A static site is over the per-file size or file-count limit. The message lists the files. |
| "This link name can't be used for publishing." | Change the link name and publish again; your code is fine. |
| "Publishing is busy for a moment" | Nothing is wrong with your app. Publish again in a few minutes. |
| "…a problem on our side, not in your app." | Ours to fix. Publish again in a few minutes. |
Fix with AI on every failure
Every failure shows Fix with AI and Try again. When you use Fix with AI, the agent receives the failure's type and the full build or app output privately, in its own context. If something in your app is wrong, it fixes it. If nothing is — a busy moment, or a problem on our side — it can simply publish again. You don't have to work out which kind of failure it was.
Problems after going live
A publish can succeed and the app fail a few minutes later. Mythex checks published apps regularly. If a live app keeps crashing, or keeps running but stops accepting connections, the publish is marked failed, you get an email, and the project shows the message with Fix with AI. What the app printed is saved for the agent to read.
Size limits checked before upload
For static sites, every file's size and the total file count are checked before anything is uploaded. If something is over, you get one message listing every file that's too large, instead of a failure part way through.
Why we built it
A failed publish used to show whatever the tools behind publishing had printed. In one week in late September, most failures showed builders text that was ours to deal with, not theirs: billing contacts, internal version numbers, registry paths, storage errors. Fix with AI then pasted that same text into the chat. People were being asked to debug our infrastructure.
Some of it was also simply wrong. An app that never listened on its port was reported as "a problem on our side", when the fix was in the app. A static file over the size limit was reported the same way — and publishing again could never work.
And every part of Mythex that reacted to a failure — the dialog, the notifications, Fix with AI, our own alerts — used to work out what had happened by matching words in the error text. That broke whenever the wording changed. Now the type is recorded where the failure happens, and everything else reads the type.
We applied the same rule to other errors while we were there:
- Chat. If the connection drops while a reply is streaming, you now see our sentence instead of the browser's "Load failed" or "Failed to fetch".
- Custom domains. Messages about buying or connecting a domain are now picked from the response's status and codes, instead of passing on the domain provider's own sentences.
- Image generation. The card shows our message; the agent gets the service's detail.
How to use it
- Publish as usual from the Publish button.
- If it fails, read the one-line message in the dialog.
- Click Fix with AI. The agent reads the build output or your app's logs, fixes what's wrong, and republishes if nothing in the app needed fixing.
- Or click Try again to publish the same version again — the right choice for "busy for a moment" and "a problem on our side".
- If the message is about the link name, change the link name before publishing again. For any other error, keep the same name.
Limits
- Some failures show different buttons: a taken link name suggests other names, and running out of credits offers a way to add credits instead.
- Static sites have a per-file limit of about 25–30 MB, depending on the kind of site, and up to 20,000 files. Large files are better kept in storage and linked to.
- Failed publishes from before this change don't have a type, so they show a neutral line rather than a specific reason.
- If "a problem on our side" keeps happening, contact support with the project ID and link name.
The full list of messages and what to do about each is in publish troubleshooting. If you're fixing a stubborn app by hand, our guide on how to debug an AI-built app walks through it. And for what happens to a live site while you republish, see your published app now stays up while you republish it.