Deploy failed or site slow? Let AI read the logs and fix it
Where BrewInTH's logs are, which lines matter, how to hand them to an AI without risking your data, and how to restore the last version in one click.
A failed deploy is a normal part of building websites; professional developers hit one every week. The trouble is the screen: The release did not succeed, followed by a log hundreds of lines long. If you did not write the code yourself, it is hard to know where to start.
The good news is that AI reads logs far better than people do. This guide shows where the logs live on BrewInTH, which lines matter, how to hand them to an AI so it fixes the right thing, and how to put the previous version back in one click when you are in a hurry.
In short
✅ When a deploy fails, the current version usually keeps serving (except projects with persistent /data storage), so no panic
✅ Each release's log is under the Releases tab › Release history, with search, copy and download
✅ Look for three markers first:[release command],[readiness]and[app output]
✅ Give the log to the AI in the same chat, or let the AI read it itself through the link + token, and ask it to fix and check the live site
✅ In a hurry? Click Restore this release on the previous version, then fix calmly
Does a failed deploy break my site?
Usually not. BrewInTH gets the new version ready first and only then moves visitors to it. If the build fails, the release command fails, or the app never starts, visitors keep seeing the current version.
The exception is a project with persistent storage (/data): the platform has to stop the current version before starting the new one, so if the new one fails, the site may stay down until it is fixed or rolled back. For those sites, always keep the rollback in mind (see below).
Where the logs are
A project page has two kinds of log:
- Release logs: Releases tab › Release history. Every deploy has its own log, from the build until the app is ready. The newest one opens by itself when it failed. There is a Search the log box and Copy and Download buttons.
- Logs of the running app: the Logs tab, then Fetch logs, shows what the app prints while people use it. Use it when the deploy worked but some page errors. (Static sites have no such tab: there is no running app.)
Reading the log: three markers to look for first
You do not need to read every line. Use Search the log to find these markers, then read the lines around them.
- Build failed: read the last lines of the build part. Usually a package that would not install, a missing lockfile, or code that does not compile.
[release command]: the output of the release command, e.g. creating database tables (a migration). Failures usually mean wrong database settings or a buggy migration.[readiness]: the platform opens the readiness path (/by default) and needs a 2xx or 3xx within 5 minutes. A 500 usually means a missing setting or table; a 404 usually means the wrong health path.[app output]: the app's last words before it exited. If the app starts and dies three times in a row, the platform stops that release at once and attaches these lines. They usually say exactly what is missing, such as noJWT_SECRETor no database connection.
Getting the AI to fix it: two ways
Way 1: the AI reads it itself through the link + token (recommended)
If you use an AI that works on your computer (Claude Code, Codex, Cursor, Windsurf) and its token has not expired, it can read the deploy logs and the app's logs itself and have the platform open the live site to check, with nothing to copy. Tell it:
The latest deploy on BrewInTH failed. Find the cause and fix it.
1. Read the latest deploy's log; look at [release command], [readiness] and [app output] first.
2. Tell me the cause in plain words before changing anything.
3. Fix the root cause. Never delete database data, never run migrate:fresh or any wiping command.
4. Deploy again, then check the live home page and the page that broke (use site_check).
5. If it is not fixed after 3 attempts, stop and summarise what you tried.Points 3 and 5 matter. Point 3 stops the AI from "fixing" things by wiping the database; point 5 stops it from looping until the site is worse than before.
Token expired? Click Create the AI link and token (automatic) on the project page and use the Continue earlier work (the old token expired) box: copy its short message into the same chat and the AI picks up where it stopped.
Way 2: copy the log into the chat
Works with any AI, including chat in the browser.
- Releases tab › Release history: open the failed release's log.
- Click Copy (for a very long log, click Download and attach the file).
- Paste it with "This is the log of a failed deploy on BrewInTH. What is the cause and how do I fix it?"
Common causes and what to ask the AI
- Wrong port: the app must listen on the
PORTvariable on0.0.0.0. The[readiness]lines usually say the app could not be reached. - A missing setting such as
JWT_SECRET,APP_KEYor an API key:[app output]names the variable. Have the AI set it in the App settings tab and deploy again (changed settings take effect from the next release). - No database connection: the code reads different variable names from the ones the platform sets, or the database is not ready yet. Have the AI compare the names in the code with the project database's connection details.
- Tables do not exist yet: the home page answers 500. Have the AI set a release command for the migration.
- Wrong health path: an API-only app may have no
/page. Have the AI set a health path that answers 200 without a login, such as/health. - The build fails: a missing lockfile, or files buried in an extra folder. Have the AI rebuild the ZIP with the main files at its root.
In a hurry: put the previous version back in one click
If the new version went live but does not work (the deploy succeeded, say, but an important button is broken) and you need the site back first:
- Releases tab › Release history
- Find the previous version that worked
- Click Restore this release
The site goes back to that version's code, and the AI can fix things without the pressure. Note that a rollback changes the site's code only and does not roll back database data. If the new version changed the table structure, have the AI check that the old version still works with the current tables. Very old releases may no longer be restorable.
The site is slow: what to check first
- Slow on the first visit, then fast: on the free plan an app sleeps after a quiet spell, so the first visitor waits a moment. That is expected. Paid plans can turn sleeping off, and static sites never sleep.
- Slow all the time: have the AI use
logs_tailfor the app's log andsite_checkon the slow page to find out whether a database query or oversized images are to blame. - Large images: shrinking them and using WebP helps most sites more than anything else.
- The app runs out of memory: an app that keeps exiting leaves traces in the log. If the app really has grown, bigger plans give it more RAM and CPU.
FAQ
Does a failed deploy cost money or quota?
There is no charge per deploy, but uploaded files count toward your plan's storage. If repeated uploads fill it up, have the AI review old unused files and ask you before deleting anything.
The AI wants to delete the database and recreate it. Should I agree?
Not if the site already holds real data. Ask the AI for a fix that keeps the data, or back up first (the Backups add-on helps).
The log is too long for the chat
Use Search the log to find [app output] or the word error and copy just that part with the lines around it, or download the log and attach the file.
I did all this and it still fails
Use Talk to support in the console with the project name and the time of the deploy, and the team will take a look.
Summary
A failed deploy is not a disaster; the current site usually keeps serving. Open Release history, look for [release command], [readiness] and [app output], and let the AI read the log itself or paste it into the chat. Ask it to explain before fixing, never to wipe data, and to check the live site afterwards. In a hurry, click Restore this release first and fix later.